feat(spring): support SpringDoc @ParameterObject
#1823
Conversation
flyinfish
force-pushed
the
feature/ISSUE-1819--support-spring-at-parameterobject
branch
from
97d2460
to
04e5ad4
Compare
extension-spring/src/main/java/io/smallrye/openapi/spring/SpringParameter.java
Outdated
Show resolved
Hide resolved
|
| 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.
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.
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.
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.
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.
AFAIR, we don't support Spring's ParamObject, although we certainly could
There was a problem hiding this comment.
I don't remember how Spring behaves in this case, I would have to check and unfortunately I am short on time at the moment
There was a problem hiding this comment.
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.
@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.
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.
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?
Signed-off-by: Michael Edgar <michael@xlate.io>
MikeEdgar
force-pushed
the
feature/ISSUE-1819--support-spring-at-parameterobject
branch
from
04e5ad4
to
72c1c1c
Compare
MikeEdgar
changed the title
@ParameterObject
Signed-off-by: Michael Edgar <michael@xlate.io>
|
proposal for support of @ParameterObject as discussed in
#1819