WildFly9 JASPI Module Isolated from Application

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.

Solution

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.