Я проверил инструкции на этой странице, и он в основном выполняет те же действия, что и я. Кажется, что критическая разница заключается в содержимом его файла jboss-app.xml:
<jboss-app>
<loader-repository>
org.myapp:loader=SomeClassloader
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>
Моя система не отключает родительское делегирование, она имеет только имя загрузчика:
<jboss-app>
<loader-repository>org.myapp:loader=MyAppName</loader-repository>
</jboss-app>
Вы можете (или не можете) также установить атрибут Isolated = true в deploy/ear-deployer.xml файле JBoss:
И это прекрасно работает. Отключая родительское делегирование, вы ограничиваете способность вашего приложения взаимодействовать с контейнером любым способом, что немного экстремально. Однако, если вы пропустите эту опцию, потребуется немного бритья
Опуская опцию java2ParentDelegation=false, вы получаете ситуацию, когда любые классы в вашем EAR, которые имеют то же имя, что и классы в JBoss, будут загружаться преимущественно из EAR (что хорошо). Тем не менее, любые классы, не найденные в EAR, попадут в библиотеки JBoss. В случае jboss-local-jdbc.rar это хорошо. Однако у него могут быть специфические побочные эффекты.
Например, когда Hibernate создает фабрику сеансов, он ищет библиотеки Hibernate Search и Hibernate Validator, а также пытается их запустить. Если их нет в вашем EAR, он найдет их в библиотеках JBoss. Проблема в том, что вы часто получаете ошибку компоновщика, потому что версии Search и Validator, поставляемые с JBoss, могут быть несовместимы с Hibernate, упакованным в вашем EAR.
Решением этой проблемы является либо настройка фабрики сеансов Hibernate для отключения регистрации прослушивателей Search и Validator с использованием свойств конфигурации (hibernate.validator.autoregister_listeners=false и hibernate.search.autoregister_listeners=false), либо упаковка пакетов совместимых версий Search и Validator также в EAR.