Как вы развертываете EAR для Wildfly с разными версиями JAR, чем Wildfly?

Question

Рассмотрим случай использования:

Мы используем для Wildfly 8.2, которая включает в себя множество зависимостей неявно в том числе в загрузчиком классов самим сервером приложений. Примеры включают такие вещи, как HttpClient. Чтобы проиллюстрировать это в моем примере, мы назовем это: libaryX-v1.jar.

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

TeamA.ear нуждается в libraryX-v1.jar и полностью протестирован и сертифицирован с этой версией.

TeamB.ear нуждается в libraryX-v2.jar, в частности, новые функции для удовлетворения этих требований команд, которые не включены ни в одну другую версию.

Как мы используем оба этих EAR для Wildfly?

Если TeamA имеет бюджет для тестирования и получения сертификата с использованием librayX-v2.jar, то очевидным решением было бы обновить этот модуль в Wildfly.

Когда мы добавим к libraryX-v2.jarTeamB.ear, мы получаем следующее исключение:

java.lang.LinkageError: loader constraint violation: when resolving method "org.apache.Example.<init>(Lorg/whatever/sharedClass;)V" 
the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, com/company/teamB/exampleService, and 
the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/apache/Example, 
have different Class objects for the type org/whatever/sharedClass used in the signature 

Answer 1

Проблема возникнет только тогда, когда вы переставить объекты между внедрениями. Я предпочитаю упаковывать все необходимые библиотеки и не ссылаться на модули wildfly, поскольку они могут измениться в будущих версиях сервера. Поэтому в вашем случае вы должны упаковать библиотекуX-v1.jar в TeamA.ear, а также библиотекуX-v2.jar в TeamB.ear. На данный момент вы чисты и совместимы с будущими релизами wildfly, даже если они обновляют (или по какой-либо причине) понижают этот модуль.

Если вам необходимо обменивать объекты libraryX между этими двумя развертываниями, это не так просто, потому что разные загрузчики классов загружают разные классы. Если было так просто, что libraryX присутствовал только в одной версии, вы могли бы просто развернуть эту библиотеку и ссылаться на нее из ушей. Но в вашем случае я думаю, что есть только способ создать пользовательскую библиотеку с «классами обмена», развернуть ее и обратиться к ней. затем берет информацию об объекте обмена и создает из него новый экземпляр объекта libraryX. Вам нужен фиксированный контракт для связи с приложениями.