feat(springdoc-parameter-object): support with jakarta-query-param #1823
Conversation
flyinfish
force-pushed
the
feature/ISSUE-1819--support-spring-at-parameterobject
branch
from
97d2460
to
04e5ad4
Compare
| COOKIE_PARAM(SpringConstants.COOKIE_PARAM, Parameter.In.COOKIE, null, Parameter.Style.FORM); | ||
| COOKIE_PARAM(SpringConstants.COOKIE_PARAM, Parameter.In.COOKIE, null, Parameter.Style.FORM), | ||
| PARAMETER_OBJECT(SpringConstants.PARAMETER_OBJECT, null, null, null), | ||
| JAKARTA_QUERY_PARAM(SpringConstants.JAKARTA_QUERY_PARAM, Parameter.In.QUERY, null, Parameter.Style.FORM); |
There was a problem hiding this comment.
Why is this needed ? (The Jakarta one)
|
| 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.
@geoand - can you comment on this comment: #1823 (comment)
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.
proposal for support of @ParameterObject as discussed in
#1819