PicketLink has compile-time dependency on JBoss library (causing ClassCastException)

[jeanluc]

I've traced the exception given further below to the compile-time dependency on jbosssx.jar defined by org.picketlink:picketlink-fed-core:jar:1.0.4

jbosssx.jar is a library coming with JBoss, so why is the dependency not marked as 'provided' instead? BTW, JBoss 5.1.GA comes with 2.0.3.SP1 not 2.0.4, in case it makes a difference.

mvn dependency:tree

[..snip]]

[INFO] +- org.picketlink:picketlink-seam:jar:1.0.4.final:compile
[INFO] |  +- org.picketlink:picketlink-fed-model:jar:1.0.4.final:compile
[INFO] |  |  +- org.picketlink:picketlink-xmlsec-model:jar:1.0.4.final:compile
[INFO] |  |  \- org.jboss.security:jbossxacml:jar:2.0.4:compile
[INFO] |  +- org.picketlink:picketlink-fed-api:jar:1.0.4.final:compile
[INFO] |  |  +- org.picketlink:picketlink-fed-core:jar:1.0.4.final:compile
[INFO] |  |  |  +- apache-logging:commons-logging-api:jar:1.0.3:compile
[INFO] |  |  |  \- org.jboss.security:jbosssx:jar:2.0.4:compile

java.lang.ClassCastException: org.jboss.security.RunAsIdentity cannot be cast to org.jboss.security.RunAsIdentity
    at org.jboss.web.tomcat.security.SecurityAssociationActions.popRunAsIdentity(SecurityAssociationActions.java:302)
    at org.jboss.web.tomcat.security.RunAsListener.instanceEvent(RunAsListener.java:97)
    at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:296)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
    at org.picketlink.identity.seam.federation.ExternalAuthenticationFilter.doFilter(ExternalAuthenticationFilter.java:134)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
    at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
    at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
    at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
    at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
    at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
    at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

[jeanluc]

Actually, same dependency issue exists for jbossxacml.jar (as with jbosssx.jar, this one is present in jboss-5.1.0.GA/common/lib). Granted, this didn't cause any problems, but the jar was deployed in the EAR's lib.

[marcelkolsteren]

I think that the JBossSX jar doesn't have provided scope, because the PicketLink federation core is not limited to the JBoss application server. Servlet containers such as Tomcat are also supported.

By the way, this class casting problem is new to me. In my own business application, which is deployed as an ear, the war file inside the ear has a library directory that contains jbosssx-2.0.4.jar. But it runs fine on JBoss AS 5.1.0. Maybe it's because I configured a class loader repository in my jboss-app.xml:

<loader-repository>org.jboss.seam:loader=mi-ear</loader-repository>

[jeanluc]

In my case, the jars are in EAR/lib (so it's a different classloader). I did have a loader-repository already.

I solved it by adding an exclusion for the dependencies coming through PicketLink and adding a 'provided' dependency on the specific version supplied with JBoss 5.1.GA, so pom.xml looks like below.

        <dependency>
            <groupId>org.jboss.security</groupId>
            <artifactId>jbosssx</artifactId>
            <version>2.0.3.SP1</version> <!--as provided with JBoss 5.1.GA-->
            <scope>provided</scope>
        </dependency>
        <dependency>
          <groupId>org.picketlink</groupId>
            <artifactId>picketlink-seam</artifactId>
            <version>1.0.4.final</version>
            <exclusions>
              <exclusion>
              <groupId>sun-jaxb</groupId>
              <artifactId>jaxb-api</artifactId>
            </exclusion>
            <exclusion>
              <groupId>sun-jaxb</groupId>
              <artifactId>jaxb-impl</artifactId>
            </exclusion>
            <exclusion>
              <groupId>stax</groupId>
              <artifactId>stax-api</artifactId>
            </exclusion>
            <exclusion>
              <groupId>apache-log4j</groupId>
              <artifactId>log4j</artifactId>
            </exclusion>
            <exclusion>
              <groupId>javax.persistence</groupId>
              <artifactId>persistence-api</artifactId>
            </exclusion>
            <exclusion>
              <groupId>org.jboss.security</groupId>
              <artifactId>jbosssx</artifactId>
            </exclusion>
            <exclusion>
              <groupId>org.jboss.security</groupId>
              <artifactId>jbossxacml</artifactId>
            </exclusion>
          </exclusions>
        </dependency>

[marcelkolsteren]

Ok, so you have PicketLink as an ear dependency, not as a war dependency? I'm curious to know why. I'd argue that the PicketLink dependency should be as close as possible to the module that needs it, which is only the war module.

[jeanluc]

Your point is valid - I'll try that.