Getting CAS 6.4.5 to run on Wildfly 24
259 views
Skip to first unread message
Shane Claggett
Feb 9, 2022, 8:14:17 PM2/9/22
to CAS Community
Hi all,
I've just worked through getting CAS 6.4.5 to run on Wildfly 24 and want to post the steps and the issues encountered for two reasons: to see if anyone has a better idea of how to solve them, and to document the process for anyone else that needs to do the same.
I started with an autogenerated LDAP CAS WAR overlay from here, then applied the external servlet container configuration from here. Specifically, this was added to build.gradle:
implementation "org.apereo.cas:cas-server-webapp:${project.'cas.version'}"
And the file jboss-deployment-structure.xml was added to src/main/webapp/WEB-INF:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported" />
</dependencies>
</deployment>
</jboss-deployment-structure>
Additionally, both appServer and tomcatVersion in gradle.properties were set to blank as suggested by a recent thread on this mailing list here.
However, cas.war failed to deploy on Wildfly 24 with a series of exceptions. Several appeared to be related and were all similar to:
2022-02-08 14:21:39,715 WARN [org.jboss.modules.define] (Weld Thread Pool -- 3) Failed to define class org.springframework.http.server.reactive.ServletHttpHandlerAdapter$HandlerResultSubscriber in Module "deployment.cas.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/springframework/http/server/reactive/ServletHttpHandlerAdapter$HandlerResultSubscriber (Module "deployment.cas.war" from Service Module Loader): org/reactivestreams/Subscriber
A bit of searching lead to the idea to add the following dependency to build.gradle:
implementation "org.reactivestreams:reactive-streams"
That fixed the above-mention exceptions. One more exception was present and stopping the webapp from deploying:
2022-02-08 14:28:12,800 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cas.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."cas.war".WeldStartService: Failed to start service
at org.jb...@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
at org.jb...@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type Validator with qualifiers @Default
at injection point [UnbackedAnnotatedField] @Inject private org.hibernate.validator.cdi.internal.interceptor.ValidationInterceptor.validator
at org.hibernate.validator.cdi.internal.interceptor.ValidationInterceptor.validator(ValidationInterceptor.java:0)
Possible dependencies:
- org.apache.bval.cdi.ValidatorBean@5b7cf57c,
- ValidatorBean [id=org.hibernate.validator.cdi.internal.ValidatorBean_default]
It appeared two default ValidatorBeans exist. Unzipping cas.war and grepping for "ValidatorBean" identifies bval-jsr-2.0.5.jar and spring-context-5.3.9.jar as the culprits. A bit of internet searching lead to the idea of setting the following system property:
bval.in-container=true
This was done by modifying standalone.conf and restarting Wildfly, at which point the exception above disappeared and was replaced by a new one:
2022-02-08 16:36:37,466 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 98) MSC000001: Failed to start service jboss.deployment.unit."cas.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."cas.war".undertow-deployment: java.lang.NoSuchFieldError: EMPTY_BYTE_ARRAY
at org.wildfly.ext...@24.0.0.Final//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.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jbos...@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.jbos...@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513)
Caused by: java.lang.NoSuchFieldError: EMPTY_BYTE_ARRAY
at deployment.cas.war//org.apache.logging.log4j.core.config.ConfigurationSource.<clinit>(ConfigurationSource.java:56)
at deployment.cas.war//org.apache.logging.log4j.core.config.NullConfiguration.<init>(NullConfiguration.java:32)
at deployment.cas.war//org.apache.logging.log4j.core.LoggerContext.<clinit>(LoggerContext.java:85)
at deployment.cas.war//org.apache.logging.log4j.core.async.AsyncLoggerContextSelector.createContext(AsyncLoggerContextSelector.java:46)
at deployment.cas.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:218)
at deployment.cas.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:136)
at deployment.cas.war//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:253)
at deployment.cas.war//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:181)
at deployment.cas.war//org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:172)
at deployment.cas.war//org.apache.logging.log4j.web.Log4jWebInitializerImpl.start(Log4jWebInitializerImpl.java:108)
at deployment.cas.war//org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:57)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:204)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:187)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:255)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:105)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:87)
... 8 more
Further investigation suggested excluding log4j, so jboss-deployment-structure.xml became:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported" />
</dependencies>
<exclusions>
<module name="org.apache.logging.log4j.api" />
</exclusions>
</deployment>
</jboss-deployment-structure>
After which the CAS webapp finally deployed. Ta-dah!
I've just worked through getting CAS 6.4.5 to run on Wildfly 24 and want to post the steps and the issues encountered for two reasons: to see if anyone has a better idea of how to solve them, and to document the process for anyone else that needs to do the same.
I started with an autogenerated LDAP CAS WAR overlay from here, then applied the external servlet container configuration from here. Specifically, this was added to build.gradle:
implementation "org.apereo.cas:cas-server-webapp:${project.'cas.version'}"
And the file jboss-deployment-structure.xml was added to src/main/webapp/WEB-INF:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported" />
</dependencies>
</deployment>
</jboss-deployment-structure>
Additionally, both appServer and tomcatVersion in gradle.properties were set to blank as suggested by a recent thread on this mailing list here.
However, cas.war failed to deploy on Wildfly 24 with a series of exceptions. Several appeared to be related and were all similar to:
2022-02-08 14:21:39,715 WARN [org.jboss.modules.define] (Weld Thread Pool -- 3) Failed to define class org.springframework.http.server.reactive.ServletHttpHandlerAdapter$HandlerResultSubscriber in Module "deployment.cas.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/springframework/http/server/reactive/ServletHttpHandlerAdapter$HandlerResultSubscriber (Module "deployment.cas.war" from Service Module Loader): org/reactivestreams/Subscriber
A bit of searching lead to the idea to add the following dependency to build.gradle:
implementation "org.reactivestreams:reactive-streams"
That fixed the above-mention exceptions. One more exception was present and stopping the webapp from deploying:
2022-02-08 14:28:12,800 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cas.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."cas.war".WeldStartService: Failed to start service
at org.jb...@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
at org.jb...@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type Validator with qualifiers @Default
at injection point [UnbackedAnnotatedField] @Inject private org.hibernate.validator.cdi.internal.interceptor.ValidationInterceptor.validator
at org.hibernate.validator.cdi.internal.interceptor.ValidationInterceptor.validator(ValidationInterceptor.java:0)
Possible dependencies:
- org.apache.bval.cdi.ValidatorBean@5b7cf57c,
- ValidatorBean [id=org.hibernate.validator.cdi.internal.ValidatorBean_default]
It appeared two default ValidatorBeans exist. Unzipping cas.war and grepping for "ValidatorBean" identifies bval-jsr-2.0.5.jar and spring-context-5.3.9.jar as the culprits. A bit of internet searching lead to the idea of setting the following system property:
bval.in-container=true
This was done by modifying standalone.conf and restarting Wildfly, at which point the exception above disappeared and was replaced by a new one:
2022-02-08 16:36:37,466 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 98) MSC000001: Failed to start service jboss.deployment.unit."cas.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."cas.war".undertow-deployment: java.lang.NoSuchFieldError: EMPTY_BYTE_ARRAY
at org.wildfly.ext...@24.0.0.Final//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.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jbos...@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.jbos...@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513)
Caused by: java.lang.NoSuchFieldError: EMPTY_BYTE_ARRAY
at deployment.cas.war//org.apache.logging.log4j.core.config.ConfigurationSource.<clinit>(ConfigurationSource.java:56)
at deployment.cas.war//org.apache.logging.log4j.core.config.NullConfiguration.<init>(NullConfiguration.java:32)
at deployment.cas.war//org.apache.logging.log4j.core.LoggerContext.<clinit>(LoggerContext.java:85)
at deployment.cas.war//org.apache.logging.log4j.core.async.AsyncLoggerContextSelector.createContext(AsyncLoggerContextSelector.java:46)
at deployment.cas.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:218)
at deployment.cas.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:136)
at deployment.cas.war//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:253)
at deployment.cas.war//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:181)
at deployment.cas.war//org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:172)
at deployment.cas.war//org.apache.logging.log4j.web.Log4jWebInitializerImpl.start(Log4jWebInitializerImpl.java:108)
at deployment.cas.war//org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:57)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:204)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:187)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535)
at io.undert...@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:255)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:105)
at org.wildfly.ext...@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:87)
... 8 more
Further investigation suggested excluding log4j, so jboss-deployment-structure.xml became:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported" />
</dependencies>
<exclusions>
<module name="org.apache.logging.log4j.api" />
</exclusions>
</deployment>
</jboss-deployment-structure>
After which the CAS webapp finally deployed. Ta-dah!
Shane Claggett
Feb 10, 2022, 12:58:52 PM2/10/22
to CAS Community, Shane Claggett
As an addendum, I was unable to get LDAP to work until I changed the dependency of the autogenerated LDAP CAS WAR overlay from:
implementation "org.apereo.cas:cas-server-support-pm-ldap"
to:
implementation "org.apereo.cas:cas-server-support-ldap"
I'm not sure what the difference between the two is or if that's a bug in the autogenerated overlay or not.
Ray Bon
Feb 11, 2022, 11:27:50 PM2/11/22
to cas-...@apereo.org, shanec...@gmail.com
Shane,
The line with 'pm' is the password management feature; The one without is login.
Ray
On Thu, 2022-02-10 at 09:54 -0800, Shane Claggett wrote:
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.
--
Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | rb...@uvic.ca
I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands, and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.
Shane Claggett
Feb 19, 2022, 12:23:35 PM2/19/22
to Ray Bon, cas-...@apereo.org
Thank you Ray, that clarifies things. We don’t use CAS to manage LDAP passwords so the one without password management is the right choice for us.
Pablo Vidaurri
Jun 13, 2022, 4:03:23 PM6/13/22
to CAS Community, shanec...@gmail.com, cas-...@apereo.org, Ray Bon
Also running on wildfly. After upgrade from 6.3.x to 6.5.4 getting the validator error too. What does bval.in-container=true actually do? I would think adding an exclusion to jboss-deployement-structure.xml would be a better solution.
-psv
Shane Claggett
Jun 14, 2022, 12:18:05 AM6/14/22
to Pablo Vidaurri, CAS Community, Ray Bon
It appears to be preventing Apache's bval library from adding its own ValidatorBean implementation:
The presence of two ValidatorBeans was causing an ambiguous dependency error; adding the variable was a work around. I didn't try adding an exclusion but it might be a better solution.
Let us know if you get it to work that way.
Pablo Vidaurri
Jun 15, 2022, 1:47:13 PM6/15/22
to CAS Community, shanec...@gmail.com, CAS Community, Ray Bon, Pablo Vidaurri
I have included the "weld" exclusion .... seems to be working. My complete jboss-deployment-structure.xml below:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported" />
</dependencies>
<deployment>
<dependencies>
<module name="jdk.unsupported" />
</dependencies>
<exclude-subsystems>
<subsystem name="jaxrs" />
<subsystem name="weld" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
<subsystem name="jaxrs" />
<subsystem name="weld" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
Shane Claggett
Jun 16, 2022, 11:46:50 PM6/16/22
to Pablo Vidaurri, CAS Community, Ray Bon
Excellent, thanks for figuring that out.
Reply all
Reply to author
Forward
0 new messages