Springdoc-openapi: Type information is lost on wildcard generic operation parameters or return types

Created on 16 Feb 2020  路  2Comments  路  Source: springdoc/springdoc-openapi

If a controller operation has a parameter or return type with a wildcard generic type, the type information is lost and any customizers will see the generically typed property of the class as just an Object rather than the upper bound of the type parameter.

This is fairly complex so I've created an example on a fork of the project: https://github.com/robfletcher/springdoc-openapi/commit/6f212b22caecdfb1d6d5e3a048a86384108166f5

When considering the parameter and response types of the controller method here: https://github.com/robfletcher/springdoc-openapi/commit/6f212b22caecdfb1d6d5e3a048a86384108166f5#diff-3cea84ffe0d7e0808cc1ed9cd9c1fe9aR16-R18

With the wildcard the schemas in the API treat the PetRecord.pet property as just an object. If I change the generic declarations on the controller to PetRecord<? extends Pet> then it works correctly. However, this shouldn't be necessary since that is just re-declaring the same variance as on the PetRecord class. Removing the generic type altogether also works (with a compiler warning). I originally ran into this problem in a Kotlin codebase where omitting the generic type is not possible.

Most helpful comment

Hi @robfletcher,

As you know we rely on swagger-core official libraries.
The behaviour that you are describing is related to swagger-core. There is still some related issues:

You can use the attached ModelConverter, is a kind of fix and should help you achieve your goal.
Let me know if that helps, so we can plan to integrate it in future releases:

All 2 comments

Hi @robfletcher,

As you know we rely on swagger-core official libraries.
The behaviour that you are describing is related to swagger-core. There is still some related issues:

You can use the attached ModelConverter, is a kind of fix and should help you achieve your goal.
Let me know if that helps, so we can plan to integrate it in future releases:

Thanks, that does help.

I might amend it slightly as in my case it would make sense to always resolve using the raw type even when a bound _is_ specified, but that may be specific to my use case.

Was this page helpful?
0 / 5 - 0 ratings