Excellent, thanks for figuring that out. > On Jun 15, 2022, at 10:47 AM, Pablo Vidaurri <[email protected]> wrote: > > 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> > <exclude-subsystems> > <subsystem name="jaxrs" /> > <subsystem name="weld" /> > </exclude-subsystems> > </deployment> > </jboss-deployment-structure> > > On Monday, June 13, 2022 at 11:18:05 PM UTC-5 [email protected] wrote: > It appears to be preventing Apache's bval library from adding its own > ValidatorBean implementation: > > https://github.com/apache/bval/blob/master/bval-jsr/src/main/java/org/apache/bval/cdi/BValExtension.java > > <https://github.com/apache/bval/blob/master/bval-jsr/src/main/java/org/apache/bval/cdi/BValExtension.java> > > 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. > >> On Jun 13, 2022, at 1:03 PM, Pablo Vidaurri <[email protected] >> <applewebdata://DBA173DF-41EB-472A-9520-610CCD77087F>> wrote: >> >> 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 [email protected] >> <http://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 <[email protected] <>> 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 >>>>> [email protected]//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) >>>>> at >>>>> [email protected]//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) >>>>> at >>>>> [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) >>>>> at >>>>> [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) >>>>> at >>>>> [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) >>>>> at >>>>> [email protected]//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 >>>>> [email protected]//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 >>>>> [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) >>>>> at >>>>> [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) >>>>> at >>>>> [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) >>>>> at >>>>> [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) >>>>> at java.base/java.lang.Thread.run(Thread.java:829) >>>>> at >>>>> [email protected]//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 >>>>> [email protected]//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:204) >>>>> at >>>>> [email protected]//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:187) >>>>> at >>>>> [email protected]//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) >>>>> at >>>>> [email protected]//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) >>>>> at >>>>> [email protected]//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) >>>>> at >>>>> [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) >>>>> at >>>>> [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) >>>>> at >>>>> [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) >>>>> at >>>>> [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1535) >>>>> at >>>>> [email protected]//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:255) >>>>> at >>>>> [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:105) >>>>> at >>>>> [email protected]//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 <tel:(250)%20721-8831> | CLE 019 | [email protected] <> >>> >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/7077525F-35BF-4CE2-A7C8-B7129E2E228D%40gmail.com.
