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 On Saturday, February 19, 2022 at 11:23:35 AM UTC-6 shanec...@gmail.com wrote: > 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. > > > On Feb 10, 2022, at 12:40 PM, Ray Bon <rb...@uvic.ca> wrote: > > 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. > > 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. > > On Wednesday, February 9, 2022 at 5:14:17 PM UTC-8 Shane Claggett wrote: > > 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.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! > > > -- > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 <(250)%20721-8831> | 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. > > > -- - 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/83f5ef46-2d6e-4a22-92de-475ca4960625n%40apereo.org.
