WildFly9 JASPI Module Isolated from Application

Question

I'm trying to create a custom JASPI ServerAuthModule totally isolated from my EAR application. It depends on a legacy version of spring framework 2.5.5. I'm running WildFly 9.0.2.Final.

I defined a proper security domain:

<security-domain="sample">
    <authentication-jaspi>
        <login-module-stack name="...">
          <login-module code="..." flag="...">
            <module-option name="..." value="..."/>
          </login-module>
        </login-module-stack>
        <auth-module code="..." login-module-stack-ref="...">
          <module-option name="..." value="..."/>
        </auth-module>
    </authentication-jaspi>
</security-domain>

And then defined a custom JBoss Module for my Auth-Module dependencies.

$WILDFLY/modules/com/my/module/main/module.xml
$WILDFLY/modules/com/my/module/main/spring-core-2.5.5.jar 
$WILDFLY/modules/com/my/module/main/etc.jar (..)

Then I hooked my module as a picket box dependency.

cat $WILDFLY/system/layers/base/modules/org/picketbox/main/module.xml

<module xmlnx="..." name="org.picketbox">
   ...
   <dependency>
      ...
      <module name="org.my.module" />
   </dependency>
</module>

When I try to deploy a common my-app.ear that ships my-app.war with jboss-web.xml that points to "sample" security-domain, it successfully finds the classes I wanted, starts JASPI lifecycle, but then when it starts creating Spring Context and Spring Beans it falls on the my-app.ear.my-app.war Module Classloader and as expected doesn't find the classes.

ClassNotFoundException: com.my.module.ClassX from [Module "deployment.my-app.ear.my-app.war:main" from Service Module Loader]

I don't want to add com.my.module as a dependency in jboss-deployment-structure.xml . Doing that makes application work as desired. Although I need it isolated.

My questions are:

• Is it possible to isolate the JASPI module classes from my application?
• Is this approach (hooking as org.picketbox dependency) recommended?
• Is it a Spring Framework 2.5.5 limitation? Maybe it uses a Classloader other than the Current Thread class loader.

Thanks in advance.

Answer 1

I found an interesting Guide that explains us a lot about JBoss Modules and Class Loading issues.

Here: https://developer.jboss.org/wiki/ModuleCompatibleClassloadingGuide

It says that TCCL can be a cancer in certain cases.

I found that legacy Spring 2.5.5 uses TCCL to load classes and instantiate its beans.

To correct this behavior I extended ClassPathXmlApplicationContext and overrode getClassLoader() that originally gets from TCCL ( ClassUtils.getDefaultClassLoader ).

Everything started to work, isolated from main app. Problem solved.

If anyone is trying to do some isolated module implementation and gets weird behavior, I suggest to start suspecting from your underlying frameworks.

Answer 2

Another option to isolate the JASPIC module (SAM) from your application is by deploying it as a separate war.

This can be done by using the programmatic option to register a SAM, but pass a null for the application context ID. The SAM will then be usable for all other archives deployed on the same AS.