-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
RESTEasy Reactive: multipart form improvements #27526
Conversation
This comment has been minimized.
This comment has been minimized.
@Sgitario you might also be interested in reviewing this |
418845b
to
c6220ea
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
Apart from the comments in the review, I'm not a big fan of doing @RestForm(FileUpload.ALL)
to load a list of FileUpload List<FileUpload>
.
Also, if possible and only if it's easy, we could move the converters into the common module, so it's reused by both the client and the server.
The rest of the changes look good to me.
@@ -744,35 +744,42 @@ REST Client Reactive support multipart messages. | |||
REST Client Reactive allows sending data as multipart forms. This way you can for example | |||
send files efficiently. | |||
|
|||
To send data as a multipart form, you need to create a class that would encapsulate all the fields | |||
to be sent, e.g. | |||
To send data as a multipart form, you can just use the regular `@RestForm` 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.
We should mention the regular JAX-RS annotation @FormParam
here.
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 guess… In the server guide we avoid mentioning these annotations to not confuse users.
@@ -809,7 +830,7 @@ Then, create an interface method that corresponds to the call and make it return | |||
@GET | |||
@Produces(MediaType.MULTIPART_FORM_DATA) | |||
@Path("/get-file") | |||
FormDto data sendMultipart(); | |||
FormDto data receiveMultipart(); |
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.
we're sending a multipart object, not receiving, right ?
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.
Well, from the PoV of the client, we're receiving one, we're not sending anything, especially not from a GET request.
...ava/io/quarkus/resteasy/reactive/server/test/multipart/ErroneousParamMultipartInputTest.java
Outdated
Show resolved
Hide resolved
...ment/src/test/java/io/quarkus/resteasy/reactive/server/test/multipart/MultipartResource.java
Outdated
Show resolved
Hide resolved
...ment/src/test/java/io/quarkus/resteasy/reactive/server/test/multipart/MultipartResource.java
Outdated
Show resolved
Hide resolved
Well, consider that the semantics of The new way of doing his, by explicitely overriding the name to a meaningful constant
The server doesn't actually need the primitive converters, because it will generate them if they're required. The client should do the same, possibly by sharing the server code which generates the converters, but that's not for this issue. |
c6220ea
to
44db973
Compare
This comment has been minimized.
This comment has been minimized.
FWIW, the test failures do seem related |
Damn, look like I broke quite a few TCK tests :( |
|
will build the native binary and run the tests.
|
Thanks. |
I was able to fix all the test issues, except the native image one. It's throwing a 500, I guess I need to find out how to make it log the cause. |
It's a reflection issue, apparently. |
OK, the tests should pass now. BTW @geoand I couldn't find any way to make RR print the exceptions, no setting, no docs about it, and nothing in the code that leads me to think we even log exceptions before we map them. Is that true? If yes, shouldn't we add a setting or log them on error level or something? |
Guys, I'd love a review on this, in particular about the docs and changes, and an opinion on the impact of the breaking change regarding obtaining all But can we not merge this until I get back from PTO at the end of september? Otherwise I won't be able to help with any bugs. |
I think you are probably right... |
Turning to draft to avoid premature merging |
This comment has been minimized.
This comment has been minimized.
😥 |
The failure showed up in a few PRs (like quarkusio#28429 and quarkusio#27526)
The failure showed up in a few PRs (like quarkusio#28429 and quarkusio#27526)
The failure showed up in a few PRs (like quarkusio#28429 and quarkusio#27526)
The failure showed up in a few PRs (like quarkusio#28429 and quarkusio#27526)
683db74
to
7510b62
Compare
Done. |
TY |
This comment has been minimized.
This comment has been minimized.
This test failure looks unrelated. Can we merge this @gsmet and move on with our lives? :) |
- Merged support into @BeanParam handling - Deprecated @MultipartForm - Auto-detect @BeanParam classes, annotation now optional - Use ParamConverter instead of MessageBodyReader for plain text multiparts - Auto-default to Accept: urlencoded or multipart depending on types of @FormParam present - Support multipart form elements as endpoint parameters and fields - Breaking: need @restform(FileUpload.ALL) for getting all uploads
7510b62
to
03833f8
Compare
Squashed into a single commit. |
Failing Jobs - Building 03833f8
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 17 MacOS M1 #- Failing: integration-tests/mongodb-devservices
📦 integration-tests/mongodb-devservices✖
✖
✖
✖
✖
|
Updated the migration guide too. |
The failure showed up in a few PRs (like quarkusio#28429 and quarkusio#27526)
Fixes #22205
@BeanParam
and@MultipartForm
optional (any container class with fields using the@Rest*
annotations or their JAX-RS equivalents will be auto-detected as a bean param@MultipartForm
special handling into the@BeanParam
code, so that you can now have any request field in that container class (@RestCookie
and@RestForm
for example)FileUpload
,File
,Path
(for the server) andbyte[]
,Multi<Byte>
(for the client), removing need for explicit@Consumes
text/plain
for@PartType
except forFileUpload
,File
,Path
(for the server) andbyte[]
,Multi<Byte>
(for the client) which default toapplication/octet-stream
text/plain
go through theParamConverter
route instead of theMessageBodyReader/Writer
one.text/plain
norFileUpload
,File
,Path
(for the server) andbyte[]
,Multi<Byte>
(for the client) go through theMessageBodyReader/Writer
route.@MultipartForm
which is never useful anymore. Would deprecate@BeanParam
too if I could.@RestForm List<FileUpload> uploads
pattern which was special-cased to obtain all uploads with the clearer pattern@RestForm(FileUpload.ALL) List<FileUpload> uploads
. Note that this is a breaking change.I had to touch some bits that were also touched by #27474 due to parallel work.
I also saw some special support for getters/setters in multipart forms that may have fallen by the side due to bean param probably not dealing with them, but I'm not sure. I'm also not sure it's useful.