Enhance Quarkus support for Spring @RequestParam annotated parameters.

[aureamunoz]

Related to #43705

Several improvements have been implemented to enhance Quarkus support for Spring @RequestParam annotated parameters.

Support for Map and Multimap in RESTEasy

The handleMapParam method has been added to extract all URL parameters and store them in a Jakarta Map or Multimap, depending on the user’s code definition.
A new ParameterConverter (MapConverter) has been introduced to transform received parameters into a Map or Multimap when the ParameterHandler detects that the endpoint expects this type of structure.
The ResteasyReactiveRequestContext.getQueryParameter method has been modified to support these new data types.

Retrieving parameters without knowing their names

A new getParametersMap method has been added to the API, allowing retrieval of all URL parameters without requiring prior knowledge of their names.
This method integrates with ParamExtractor, which does not work directly with endpoint parameters but instead processes their characteristics (name, single/multi-value, encoding, etc.).
Since Map and Multimap cannot always be distinguished (both may contain multiple values per key), the method returns a unified Map<String, List<String>>, allowing ParamHandler to process it consistently.

Support for Spring’s MultiValueMap

A dedicated extractor, SpringMultiValueMapParamExtractor, has been created to read request parameters and store them in a Spring MultiValueMap<String, String>.
This was implemented using MethodScannerBuildItem, which detects methods with @RequestParam annotations. If the parameter type is MultiValueMap<String, String>, a specific extractor is instantiated to convert request parameters accordingly.
As a result, users can now define methods in a Quarkus @RestController with a MultiValueMap<String, String> parameter, and it will behave just like in Spring:

@PostMapping("/api/foos")
@ResponseBody
public String handle(@RequestParam MultiValueMap<String, String> params) {
    return params.toString();
}

Making @RequestParam required by default

In Spring, parameters annotated with @RequestParam are required by default unless explicitly marked as optional.
MethodScannerBuildItem is used to enforce this behavior, ensuring that parameters must have a value unless explicitly declared as optional.
If a required parameter is missing, SpringRequestParamHandler handles the response by returning a 400 Bad Request error.

Supporting multiple values in @RequestParam separated by comma

Spring allows @RequestParam List<String> to receive multiple values in a comma-separated format from the URL.
To replicate this behavior, the SpringMultiValueListParamExtractor has been added, which automatically converts these values into a List<String>.

[quarkus-bot]

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

• title should preferably start with an uppercase character (if it makes sense!)
• description should not be empty, describe your intent or provide links to the issues this PR is fixing (using Fixes #NNNNN) or changelogs

_{This message is automatically generated by a bot.}

[aureamunoz]

cc @geoand @cescoffier

[gsmet]

@aureamunoz once you're done, it's probably a good idea to squash all your commits :)

[aureamunoz]

@aureamunoz once you're done, it's probably a good idea to squash all your commits :)

Yes, of course

[aureamunoz]

I refactored with your suggestions and squashed commits

[geoand]

Thanks!

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 1c63455.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 extensions/smallrye-reactive-messaging-kafka/deployment

✖ io.quarkus.smallrye.reactivemessaging.kafka.deployment.testing.KafkaDevServicesContinuousTestingWorkingAppPropsTestCase.testContinuousTestingScenario3 - History

• io.quarkus.builder.BuildException: Build failure: Build failed due to errors [error]: Build step io.quarkus.redis.deployment.client.DevServicesRedisProcessor\#startRedisContainers threw an exception: java.lang.RuntimeException: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/redis:7 at io.quarkus.redis.deployment.client.DevServicesRedisProcessor.startRedisContainers(DevServicesRedisProcessor.java:124) at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732) at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856) - java.lang.RuntimeException

java.lang.RuntimeException: 
io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.redis.deployment.client.DevServicesRedisProcessor#startRedisContainers threw an exception: java.lang.RuntimeException: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/redis:7
	at io.quarkus.redis.deployment.client.DevServicesRedisProcessor.startRedisContainers(DevServicesRedisProcessor.java:124)
	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732)
	at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
	at io.quarkus.builder.BuildContext.run(BuildContext.java:255)
	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)