You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and the following return types for request methods.
record CommonImplementorUser(FirstHierarchyfirstHierarchy, SecondHierarchysecondHierarchy) {}
record FirstHierarchyUser(FirstHierarchyfirstHierarchy) {}
record SecondHierarchyUser(SecondHierarchysecondHierarchy) {}
If we use CommonImplementorUser as return type for a request method, everything is mapped correctly, i.e.
What modules and versions of springdoc-openapi are you using: 2.5.0 [springdoc-openapi-starter-common, springdoc-openapi-starter-webmvc-api and springdoc-openapi-starter-webmvc-ui]
Expected behavior
I would always expect the following to be generated:
Additional context
I already debugged the problem, s.t. I am quite sure that, the call of io.swagger.v3.core.converter.ModelConverters#resolveAsResolvedSchema in org.springdoc.core.utils.SpringDocAnnotationsUtils#extractSchema is the problem.
io.swagger.v3.core.converter.ModelConverters#resolveAsResolvedSchema look the following:
Thus for every processed return type, a new ModelConverterContextImpl is created and used to go through the tree, if simply one context would be used for all annotated types, this would be no problem, since swagger is smart enough to extend existing types.
Therefore in one case CommonImplementor is reached from FirstHierarchy and in the other from SecondHierarchy.
However, org.springdoc.core.utils.SpringDocAnnotationsUtils#extractSchema does not actually merge the schemas, but rather "decides" for one:
Map<String, Schema> componentSchemas = components.getSchemas();
if (componentSchemas == null) {
componentSchemas = newLinkedHashMap<>();
componentSchemas.putAll(schemaMap);
}
elsefor (Map.Entry<String, Schema> entry : schemaMap.entrySet()) {
// If we've seen this schema before but find later it should be polymorphic,// replace the existing schema with this richer version.if (!componentSchemas.containsKey(entry.getKey()) ||
(!entry.getValue().getClass().equals(componentSchemas.get(entry.getKey()).getClass()) && entry.getValue().getAllOf() != null)) {
componentSchemas.put(entry.getKey(), entry.getValue());
}
}
components.setSchemas(componentSchemas);
The text was updated successfully, but these errors were encountered:
Describe the bug
Multiple superclasses of response types (i.e. via Interfaces) are not mapped correctly,
if the superclasses are used in different return types.
To Reproduce
Steps to reproduce the behavior:
Suppose the following dto hierarchy:
and the following return types for request methods.
If we use
CommonImplementorUser
as return type for a request method, everything is mapped correctly, i.e.However, if we use
FirstHierarchyUser
as return type for one request method andSecondHierarchyUser
as return type of a second, we get only:or
depending on the order of processing.
springdoc-openapi-starter-common
,springdoc-openapi-starter-webmvc-api
andspringdoc-openapi-starter-webmvc-ui
]Expected behavior
I would always expect the following to be generated:
Additional context
I already debugged the problem, s.t. I am quite sure that, the call of
io.swagger.v3.core.converter.ModelConverters#resolveAsResolvedSchema
inorg.springdoc.core.utils.SpringDocAnnotationsUtils#extractSchema
is the problem.io.swagger.v3.core.converter.ModelConverters#resolveAsResolvedSchema
look the following:Thus for every processed return type, a new
ModelConverterContextImpl
is created and used to go through the tree, if simply one context would be used for all annotated types, this would be no problem, since swagger is smart enough to extend existing types.Therefore in one case
CommonImplementor
is reached fromFirstHierarchy
and in the other fromSecondHierarchy
.However,
org.springdoc.core.utils.SpringDocAnnotationsUtils#extractSchema
does not actually merge the schemas, but rather "decides" for one:The text was updated successfully, but these errors were encountered: