-
Notifications
You must be signed in to change notification settings - Fork 89
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
feat(spring): support SpringDoc @ParameterObject
#1823
base: main
Are you sure you want to change the base?
feat(spring): support SpringDoc @ParameterObject
#1823
Conversation
97d2460
to
04e5ad4
Compare
extension-spring/src/main/java/io/smallrye/openapi/spring/SpringParameter.java
Outdated
Show resolved
Hide resolved
Quality Gate passedIssues Measures |
import jakarta.ws.rs.QueryParam; | ||
|
||
public class GreetingParam { | ||
@QueryParam("nameQuery") // "real" spring does not require this, but quarkus-spring-web does |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean neither the OpenAPI nor the actual web application work correctly without using the Jakarta REST @QueryParam
annotation in this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes that is right
@phillip-kruger this is the reason for having JAKARTA_QUERY_PARAM
in SpringParameter.java
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i did play around with https://github.com/flyinfish/spring-web-quickstart/compare/feature/adapt-to-patch?expand=1
HelloParamCheatedWithQueryParam
has the same role there as GreetingParm
above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does not seem right. At least the actual endpoint should work, even if openapi can not generate correctly. @geoand ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIR, we don't support Spring's ParamObject, although we certainly could
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, for an un-annotated POJO passed to a Spring GET
method, the properties of the POJO should be used as query parameters. These should be added to the OpenAPI even without the SpringDoc annotation. For sure, the Spring scanner shouldn't use the Jakarta annotations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MikeEdgar if we were talking spring i would agree shat scanner should not use jakarta-annotations.
since we are talking quarkus (do we? is this project used outside quarkus?) i would not be too happy if the scanner generates an api which then does not work until i add the missing jakarta-annotations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is being used in many other projects, not only Quarkus. I agree with @MikeEdgar, the fix should be that we handle the un-annotated case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've re-based this one and pushed another commit to remove the reliance on the Jakarta annotation for Spring. As we discussed earlier in this thread, Quarkus itself may still not handle this scenario (I haven't looked at the changes in Quarkus Spring since the last comment), but this at least will scan the way it should work with native Spring.
@flyinfish, would you mind reviewing the current state of this PR and let us know if it should work as needed for your OpenAPI documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MikeEdgar
sorry for late reply - Yes ist works as needed - Thank you very much!
nevertheless we moved away from spring-approach and convert our legacy apps now to proper quarkus/microprofile annotations.
anyhow for spring-users this should help!
04e5ad4
to
72c1c1c
Compare
@ParameterObject
Signed-off-by: Michael Edgar <[email protected]>
Quality Gate passedIssues Measures |
proposal for support of @ParameterObject as discussed in
#1819