-
-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SpringDoc - Adding extra object's wrong property #2959
Comments
Hi @rksvtln, First I will format the response so it is easier for a reader to interpret it. {
"SampleResponse": {
"type": "object",
"properties": {
"ting": {
"$ref": "#/components/schemas/SampleResponse"
},
"id": {
"type": "string",
"description": "ID"
},
"description": {
"type": "string",
"description": "Description"
},
"setting": {
"type": "string",
"description": "Setting"
}
}
}
} The issues stems from how swagger-core introspects methods to generate schema properties. They do not only look at the I could for example add public boolean isName() {
return false;
} to your class, and that would add a new property "name" to the schema. This is due to them removing known prefixes such as "get, set, is" to derive the parameter's name. This will of course have odd consequences when the name is setting, since set will be removed. You can play around with it yourself by using ResolvedSchema resolvedSchema = ModelConverters.getInstance(true)
.resolveAsResolvedSchema(
new AnnotatedType(SampleResponse.class).resolveAsRef(false)); A minimal case that would highlight this is if we reduce your class to public class SampleResponse {
public void setId(String id) {
}
public void setDescription(String description) {
}
public SampleResponse setting(String setting) {
return this;
}
public boolean isName() {
return false;
}
} then the generated schema for that class is {
"SampleResponse": {
"type": "object",
"properties": {
"ting": {
"$ref": "#/components/schemas/SampleResponse"
},
"id": {
"type": "string"
},
"description": {
"type": "string"
},
"name": {
"type": "boolean"
}
}
}
} |
Thanks @Mattias-Sehlstedt for the explanation! |
I would avoid having methods that are not prefixed with From my testing it looks like "thing" is dropped from the properties if you for example rename the method If your design requires you to have methods that affect the generated schema in an odd way (for example, I am interpreting your methods as being a "parameter-by-parameter-builder"), then I would suggest investigating if having @Schema(hidden = true)
public SampleResponse setting(String setting) {
return this;
} for the methods that are just part of the builder pattern. I would not use a custom ModelConverter, since in my experience that is an extreme overhead to implement, and you also have to maintain it over time. There are instead much easier and maintainable solutions, e.g., the one above: or to maybe delegate the object instantiation/construction to a separate class, so that the API-class only contains information tied to how data is (de)serialized and annotations that guides the OpenAPI-schema representation. |
Thank you @Mattias-Sehlstedt for your clear explanation. |
Describe the bug
"SampleResponse":{"type":"object","properties":{"ting":{"$ref":"#/components/schemas/SampleResponse"},"id":{"type":"string","description":"ID"},"description":{"type":"string","description":"Description"},"setting":{"type":"string","description":"Setting"}}}
To Reproduce
Steps to reproduce the behavior:
The sampleResponse in openapi json:
"SampleResponse": { "type":"object", "properties":{ "ting": { "$ref":"#/components/schemas/SampleResponse"}, "id": {"type":"string","description":"ID"}, "description": {"type":"string","description":"Description"}, "setting":{"type":"string","description":"Setting"} } }
Expected behavior
Additional context
The text was updated successfully, but these errors were encountered: