-
-
Notifications
You must be signed in to change notification settings - Fork 523
Support for nullable request parameters in Kotlin #2006
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
Comments
Thank you for your sharing and encouragements! Maybe you can add a test case to show what is not working in your side ? |
Interesting! I created a simple sample project to reproduce it and - as you said - everything works out of the box. However, the same combination of versions (including springdoc The setup we use in our product is a bit special, because we do not have the actual controller implementations available when we generate the documentation, only the interfaces. We therefore generate dynamic proxies for each controller interface to be consumed by springdoc. I created a sample project to illustrate this behavior. This project demonstrates in a test, that it does not work for dynamic proxies. If I'm correct, springdoc checks if the parameter is optional in the ParameterInfo class and uses MethodParameter#isOptional from Spring, which is aware of nullable Kotlin types. This works for normal controllers, but when using a proxy, Everything else works perfectly fine by the way! I was thinking about potential solutions, but I haven't really found something suitable here 🤔 ... |
Thank you for sharing your use case. springdoc.nullable-request-parameter-enabled=false |
@bnasslahsen That's awesome, thank you 🎉 |
Is your feature request related to a problem? Please describe.
When using springdoc-openapi in a Kotlin code base, it is annoying that parameters with a nullable type have to be marked manually as optional (
required = false
):Describe the solution you'd like
It would be nice to just leave the
required = false
out and just write:Describe alternatives you've considered
We were able to achieve this using a ParameterCustomizer. However, I believe that this should be part of springdoc-openapi instead.
PS: Thank you for your great work!
The text was updated successfully, but these errors were encountered: