WildFly currently includes a org.jboss.resteasy.resteasy-spring module in it's deliverables. It's kind of an odd module as Spring itself is not provided, but required for the module to work. The user is responsible for either installing a Spring module or including Spring in their deployment. For these reasons and also for the reason there is currently no Spring version targeting Jakarta EE 9+ this module should be removed. Note that Spring 6 will introduce compatibility with Jakarta EE 9. It also will require Java SE 17 which currently WildFly does not require as it's minimum JVM version.

A new project has been introduced which includes a Galleon Feature Pack for both Spring and the org.jboss.resteasy.resteasy-spring module. The other option is simply for the user to include the resteasy-spring-*.jar in their deployment. This seems to be a common use case for Spring applications. There is also a custom DUP (org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor) which loads the JAR on the deployment to mimic the JAR being included in the deployment.

Notes

When doing this, a change is likely needed in the org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor. What this DUP does is attempt to integrate the module as if the library is in the deployment. This is not the typical way modules are integrated, however this is a special use-case. What would likely need to change is we look early to see if the module is available. If it's not found, then we short-circuit early and not finish processing. We should use a static variable that checks for existence of the module on the DUP's first run.

Another option might be moving the DUP out to the resteasy-spring. This seems less desirable at the moment though as it would require likely introducing another subsystem.