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 | CLE 019 | [email protected]<mailto:[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/0f9052801fc36176562916fe68074674ef0fff46.camel%40uvic.ca.

Reply via email to