I want to upgrade a quarkus 2 (2.16.12) application to quarkus 3. (3.20.1). As part of that I replaced maven dependencies to quarkus-resteasy with the recommended quarkus-rest. Unfortunately the upgraded application does not start because of a DeploymentException from ResteasyReactiveJaxbProcessor.

In detail: Build step io.quarkus.resteasy.reactive.jaxb.deployment.ResteasyReactiveJaxbProcessor#registerClassesToBeBound threw an exception: jakarta.enterprise.inject.spi.DeploymentException: Cannot directly return collections or arrays using JAXB. You need to wrap it into a root element class.

It seems all return values and parameters are checked and collections without XmlRootElement annotation will trigger the exception. This is inconvenient, because we have a number of APIs that use for example List as return value or as method parameter. public List getServiceNames(List systems) { Now I could define List-Implementations to make the return parameters quarkus-rest-jaxb compatible but that seems like a fruitless exercise and it can‘t be applied to the incoming method parameters. Rewriting all APIs and implementations with xmlrootelement-annotated wrapper objects seems a bit over the top, so I was hoping for a configuration approach, i.e. a quarkus option, or at least a local approach like an annotation to be used in the implementation methods such that the existing APIs can be kept. Since I didn‘t find that I now use quarkus-rest-classic (3.20.1), i.e. quarkus-resteasy-jackson and everything works.

But I wonder, if quarkus-rest is the way to go, then String-Collections shouldn‘t be a problem. So what am I missing?