Support inheritance

[VladDrakul1986]

Hi i figured out a problem when using:

...
requestBody = @OpenApiRequestBody(...
               @OpenApiContent(from = MyRequestClass.class, type = ContentType.JSON)),

The MyRequestClass extends from MyBaseRequest since all Request should have a common set of fields. public class MyRequestClass extends MyBaseRequest implements Serializable{....}

i just get all fields having a getter in myRequestClass but not the fields defined in MyBaseRequest. This functionality was present in Javalin 4 (but need the setter and not getters).

Is this a Bug(enhancement) or I made it wrong?

I tested the behaviour for @OpenApiReponse as well, it behaves the same as @OpenApiRequestBody so it seems the @OpenApiContent doesn't process the inheritance.

[dzikoysk]

By default OpenApi only includes properties exposed by getters, not fields as fields are rarely exposed in api. You can enforce fields resolution with @OpenApiByFields on MyRequestClass class tho.

[VladDrakul1986]

my example was bad the @OpenApiByFields is a nice function but not solving my problem. More detailed example:

public class MyBaseRequest {
private String name;
private String description;
...
// getter for all
...
}

public class MyRequestClass extends MyBaseRequest implements Serializable{
private String someAdditonalField;
...
// getter for all
...
}

requestBody = @OpenApiRequestBody(...
               @OpenApiContent(from = MyRequestClass.class, type = ContentType.JSON)),

when open the swagger site only someAdditonalField is shown in the json at requestbody but not as expected name and description as well. actual json result:

{
"someAdditonalField": "string",
}

expected json result:

{
"someAdditonalField": "string",
"name": "string",
"description": "string"
}

The same behaviour can be observed for the @OpenApiReponse providing a class with inheritance.

I just mentioned the setters because in Javalin 4 the setters were needed, just as hint for people try to migrate from 4 to 5.

[dzikoysk]

I see, this is slightly associated with #87 as there's no heritage analysis atm. I'll include all properties for now and we'll see how it evolves