-
Bug
-
Resolution: Done
-
Major
-
28.0.1.Final, 29.0.1.Final
-
None
This is a similar issue than WFLY-13461 jaxrs actually depends on bean-validation, we can see the following stack trace when jaxrs alone is provisioned:
15:47:04,254 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 16) RESTEASY002225: Deploying jakarta.ws.rs.core.Application: class org.wildfly.plugins.demo.jaxrs.RestApplication 15:47:04,283 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 16) MSC000001: Failed to start service jboss.deployment.unit."ROOT.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."ROOT.war".undertow-deployment: jakarta.validation.ValidationException: RESTEASY008520: Unable to load Validation support at org.wildfly.extension.undertow@30.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:90) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.base/java.lang.Thread.run(Thread.java:829) at org.jboss.threads@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513) Caused by: jakarta.validation.ValidationException: RESTEASY008520: Unable to load Validation support at org.jboss.resteasy.resteasy-validator-provider@6.2.5.Final//org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver.getContext(AbstractValidatorContextResolver.java:82) at org.jboss.resteasy.resteasy-validator-provider@6.2.5.Final//org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:16) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:150) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:335) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:272) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:227) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:201) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:184) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:171) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:156) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:81) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResteasyDeploymentImpl.registerResources(ResteasyDeploymentImpl.java:463) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResteasyDeploymentImpl.registration(ResteasyDeploymentImpl.java:431) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResteasyDeploymentImpl.startInternal(ResteasyDeploymentImpl.java:159) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.core.ResteasyDeploymentImpl.start(ResteasyDeploymentImpl.java:124) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:134) at org.jboss.resteasy.resteasy-core@6.2.5.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:39) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:304) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:589) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:559) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow@30.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1430) at org.wildfly.extension.undertow@30.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1430) at io.undertow.servlet@2.3.7.Final//io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:605) at org.wildfly.extension.undertow@30.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:106) at org.wildfly.extension.undertow@30.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:87) ... 8 more Caused by: jakarta.validation.NoProviderFoundException: Unable to create a Configuration, because no Jakarta Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath. at jakarta.validation.api//jakarta.validation.Validation$GenericBootstrapImpl.configure(Validation.java:291) at org.jboss.resteasy.resteasy-validator-provider@6.2.5.Final//org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver.getConfig(AbstractValidatorContextResolver.java:66) at org.jboss.resteasy.resteasy-validator-provider@6.2.5.Final//org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver.getContext(AbstractValidatorContextResolver.java:76) ... 36 more 15:47:04,290 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "jaxrs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./" => "jakarta.validation.ValidationException: RESTEASY008520: Unable to load Validation support Caused by: jakarta.validation.ValidationException: RESTEASY008520: Unable to load Validation support Caused by: jakarta.validation.NoProviderFoundException: Unable to create a Configuration, because no Jakarta Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
[WFLY-18533] Simplest JAXRS app is failing when deployed in server provisioned with jaxrs
The BV support should be optional IMO. I'm not able to reproduce the issue though. I'm not seeing the org.jboss.resteasy.resteasy-validator-provider being provisioned:
jperkins@stalefish ~/projects/wildfly-extras/wildfly-jar-maven-plugin/examples/jaxrs (main *) $ ll target/bootable-jar-build-artifacts/wildfly/modules/system/layers/base/org/jboss/resteasy/ total 0 drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-atom-provider drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-client drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-client-api drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-core drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-core-spi drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-crypto drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jackson2-provider drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jaxb-provider drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jaxrs drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jsapi drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-json-binding-provider drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-json-p-provider drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-multipart-provider drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-spring drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-tracing-api
That said, it seems correct to only add the module dependency if bean-validation is available.
James Perkins
added a comment - - edited The BV support should be optional IMO. I'm not able to reproduce the issue though. I'm not seeing the org.jboss.resteasy.resteasy-validator-provider being provisioned:
jperkins@stalefish ~/projects/wildfly-extras/wildfly-jar-maven-plugin/examples/jaxrs (main *) $ ll target/bootable-jar-build-artifacts/wildfly/modules/system/layers/base/org/jboss/resteasy/
total 0
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-atom-provider
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-client
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-client-api
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-core
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-core-spi
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-crypto
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jackson2-provider
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jaxb-provider
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jaxrs
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-jsapi
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-json-binding-provider
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-json-p-provider
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-multipart-provider
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-spring
drwxr-xr-x. 1 jperkins jperkins 8 Sep 26 09:43 resteasy-tracing-api
That said, it seems correct to only add the module dependency if bean-validation is available. 
Brian Stansberry
added a comment - Note that making it optional technically leaves open the question of whether the jaxrs layer should optionally depend on bean-validation, the way it does on ee-concurrency.
jdenise@redhat.com Note that if we don't fix this in the integration, jaxrs-server is wrong as well as it's bean-validation dependency is optional, which is currently not valid.
Brian Stansberry
added a comment - Note that making it optional technically leaves open the question of whether the jaxrs layer should optionally depend on bean-validation, the way it does on ee-concurrency.
jdenise@redhat.com Note that if we don't fix this in the integration, jaxrs-server is wrong as well as it's bean-validation dependency is optional, which is currently not valid. Brian Stansberry
added a comment - jperkins-rhn I'm not an expert but from a naive POV this might be solvable by a simple change to JaxrsDependencyProcessor to wrap the addition of the RESTEASY_VALIDATOR dependency in a capability check.
Brian Stansberry
added a comment - jperkins-rhn I'm not an expert but from a naive POV this might be solvable by a simple change to JaxrsDependencyProcessor to wrap the addition of the RESTEASY_VALIDATOR dependency in a capability check. Brian Stansberry
added a comment - The fact that BV is optional in the REST spec doesn't mean it has to be optional in our implementation, so fixing it in the layer is a valid possibility.
But, having our REST integration not require BV is a nice-to-have, part of the general spirit of what we're doing with layers where we make it possible to exclude unneeded functionality.
Brian Stansberry
added a comment - The fact that BV is optional in the REST spec doesn't mean it has to be optional in our implementation, so fixing it in the layer is a valid possibility.
But, having our REST integration not require BV is a nice-to-have, part of the general spirit of what we're doing with layers where we make it possible to exclude unneeded functionality. 
Jean Francois Denise
added a comment - jperkins-rhn , it seems that we can't really fix it at the Galleon layer level (BV is optional in the REST spec) as bstansbe@redhat.com wrote.
I suppose that deploying the simplest jaxrs resource shouldn't require the bean-validation to be present. Users should be able to add explicitely bean-validation layer if they use jakarta.validation.* API. But I am not expert at all 
Jean Francois Denise
added a comment - jperkins-rhn , it seems that we can't really fix it at the Galleon layer level (BV is optional in the REST spec) as bstansbe@redhat.com wrote.
I suppose that deploying the simplest jaxrs resource shouldn't require the bean-validation to be present. Users should be able to add explicitely bean-validation layer if they use jakarta.validation.* API. But I am not expert at all
James Perkins
added a comment - jdenise@redhat.com It's not clear to me what needs to be done here. Is there a fix required for WildFly?
James Perkins
added a comment - jdenise@redhat.com It's not clear to me what needs to be done here. Is there a fix required for WildFly? Brian Stansberry
added a comment - Ah, I see that the testsuite/integration/basic layers.profile has no execution for just the jaxrs layer. WildFly Glow-driven testing will certainly help with this kind of thing.
Brian Stansberry
added a comment - Ah, I see that the testsuite/integration/basic layers.profile has no execution for just the jaxrs layer. WildFly Glow-driven testing will certainly help with this kind of thing. Jean Francois Denise
added a comment - bstansbe@redhat.com , no dependency on BV. A simple Rest endpoint: https://github.com/wildfly-extras/wildfly-jar-maven-plugin/blob/main/examples/jaxrs/src/main/java/org/wildfly/plugins/demo/jaxrs/HelloWorldEndpoint.java
Jean Francois Denise
added a comment - bstansbe@redhat.com , no dependency on BV. A simple Rest endpoint: https://github.com/wildfly-extras/wildfly-jar-maven-plugin/blob/main/examples/jaxrs/src/main/java/org/wildfly/plugins/demo/jaxrs/HelloWorldEndpoint.java Brian Stansberry
added a comment - jdenise@redhat.com Does the app use BV?
Support for BV is optional in the Jakarta REST spec. It would be nice if it were optional in WF as well.
Brian Stansberry
added a comment - jdenise@redhat.com Does the app use BV?
Support for BV is optional in the Jakarta REST spec. It would be nice if it were optional in WF as well. 
jperkins-rhn , resteasy-validator-provider is a passive dependency and should be provisioned only if all its dependencies are provisioned, so we are safe.
It happens that due to some local changes, the Bootable JAR packaging was installing all modules, so the resteasy-validator-provider was provisioned.
Sorry for the noise, I think that we can close the issue except if you think that your findings require a fix.