Test handling a multipart request part as a file based on the content-type

[michalvavrik]

Summary

Verifies: quarkusio/quarkus#29725
Test plan PR: quarkus-qe/quarkus-test-plans#120

Minor commits:

• Tag MediaTypeSelectionIT with QUARKUS-2743 - adds a tag over tests created by RESTEasy Reactive - Test selecting from multiple media types #960 as ticket QUARKUS-2743 didn't exist when I was writing the test
• Drop deprecated @MultipartForm annotation, it is surplus to requirements - the annotation has been deprecated and will be removed in the future version

Please select the relevant options.

• Bug fix (non-breaking change which fixes an issue)
• Dependency update
• Refactoring
• Backport
• New scenario (non-breaking change which adds functionality)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[rsvoboda]

Fails in "Pull Request CI / PR - Linux - JVM build - Latest Version (11) (pull_request)" do not seem related. Need some investigation though.

[rsvoboda]

Looks like you are dropping all instances of @MultipartForm. Users can still use it and mix it. What if the @MultipartForm annotation is kept here and there?

Have you tried to run the tests with older Quarkus 2.13.5.Final which should not contain the changes? Are the failure messages reasonable?

[michalvavrik]

Looks like you are dropping all instances of @MultipartForm. Users can still use it and mix it. What if the @MultipartForm annotation is kept here and there?

I understand your thinking, but as we are technical people, we can literally look into Quarkus source code and see that org.jboss.resteasy.reactive.MultipartForm is dead code. It is ignored annotation never used, with no function at all.

[michalvavrik]

Have you tried to run the tests with older Quarkus 2.13.5.Final which should not contain the changes? Are the failure messages reasonable?

As for this feature failures

• re failures - there are no exception message or failures that I know about; it doesn't throw exception as this feature is only dealing with form parts that names are not known beforehand. If you try to access these files, there are none (I can see that when I don't set config property). Also if you don't send expected file part, it is simply null, so no exception
• re trying with 2.13.5: no as I knew it was failing even with 2.13.6 without quarkus.http.body.multipart.file-content-types (tested). TBH I didn't thought about trying 2.13.5. as I read the PR and didn't thing of relevance, but I can try it if you like!

As for CI failures

• in io.quarkus.ts.messaging.kafka.reactive.streams.StrimziKafkaStreamIT#testAlertMonitorEventStream, that's flaky, super hard to debug as you can't reproduce it when you need
• keycloak stuff is CORS related, I didn't get to it yesterday, but today I'll address it in separate PR (unless someone already did)

[rsvoboda]

Need for quarkus.http.body.multipart.file-content-types - is this documented?

+1 for CORS fix, is there an upstream change? Maybe quarkusio/quarkus#29692 ...

[michalvavrik]

Need for quarkus.http.body.multipart.file-content-types - is this documented?

One step ahead of you :-) quarkusio/quarkus#30046

+1 for CORS fix, is there an upstream change? Maybe quarkusio/quarkus#29692 ...

Antonio was quicker than me #963