Модуль WildFly9 JASPI, выделенный из приложения

Question

Я пытаюсь создать пользовательский JASPI ServerAuthModule, полностью изолированный от приложения EAR. Это зависит от устаревшей версии весеннего каркаса 2.5.5. Я запускаю WildFly 9.0.2.Final.

Я определил правильный домен безопасности:

<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> 

А затем определить пользовательский JBoss модуль для моих зависимостей Auth-модуля.

$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 (..) 

Затем я подключил свой модуль как зависимость от пикета.

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

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

При попытке развернуть общий my-app.ear, что корабли my-app.war с jboss-web.xml, что указывает на «образец» безопасности-домен, он успешно находит классы, которые я хотел, начинает JÄSPI жизненный цикл, но потом, когда он начинает создавать Spring Контекст и Spring Beans он падает на my-app.ear.my-app.war Модуль Classloader и, как и ожидалось, не находит классы.

ClassNotFoundException: com.my.module.ClassX из [Модуль "deployment.my-app.ear.my-app.war: главный" от служебного модуля Loader]

Я не хочу добавить com.my.module в качестве зависимости в jboss-deployment-structure.xml. Это делает работу приложения по своему усмотрению. Хотя он мне нужен.

Мои вопросы:

• Можно выделить классы модуля JÄSPI из моего приложения?
• Этот подход (зацепление как org.picketbox зависимостей) рекомендуется?
• Является ли ограничение Spring 2.5 2.5? Возможно, он использует Classloader, отличный от загрузчика класса Current Thread.

Заранее спасибо.

Answer 1

Я нашел интересное руководство, которое объясняет нам много о проблемах модулей JBoss и классах.

Здесь: https://developer.jboss.org/wiki/ModuleCompatibleClassloadingGuide

Он говорит, что TCCL может быть рак в некоторых случаях.

Я обнаружил, что устаревшая Spring 2.5.5 использует TCCL для загрузки классов и создания экземпляров его компонентов.

Для исправления этой ситуации я продлил ClassPathXmlApplicationContext и перегрузил getClassLoader(), который первоначально поступает из TCCL (ClassUtils.getDefaultClassLoader).

Все начало работать, изолировано от основного приложения. Задача решена.

Если кто-то пытается выполнить изолированную реализацию модуля и получает странное поведение, я предлагаю начать подозревать из ваших базовых фреймворков.

Answer 2

Другой вариант изолирования модуля JASPIC (SAM) от вашего приложения - это развертывание его как отдельной войны.

Это можно сделать, используя программную опцию для регистрации SAM, но передайте null для идентификатора контекста приложения. Затем SAM будет использоваться для всех других архивов, развернутых в одной AS.