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 <https://apereo.github.io/cas/6.4.x/authentication/LDAP-Authentication.html>, then applied the external servlet container configuration from here <https://apereo.github.io/cas/development/installation/Configuring-Servlet-Container-External.html>. 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 <https://groups.google.com/a/apereo.org/g/cas-user/c/V6XEVRexxmI/m/wgxGWL-LAgAJ> . 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.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) 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) 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.extension.undertow@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.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: 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.undertow.servlet@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:204) at io.undertow.servlet@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:187) at io.undertow.servlet@2.2.8.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) at io.undertow.servlet@2.2.8.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow@24.0.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) at org.wildfly.extension.undertow@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) at org.wildfly.extension.undertow@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) at org.wildfly.extension.undertow@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) at io.undertow.servlet@2.2.8.Final//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:255) at org.wildfly.extension.undertow@24.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:105) at org.wildfly.extension.undertow@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! -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/3d2dd735-3283-4d11-9500-2103d9615d66n%40apereo.org.
