如何使用 Wildfly 提供的不同 JAR 版本将 EAR 部署到 Wildfly？

Question

考虑这个用例：

我们部署到 Wildfly 8.2，其中包括许多依赖项，隐含地包括在应用服务器本身的类加载器中。示例包括诸如 HttpClient 之类的东西。为了在我的示例中说明这一点，我们将其命名为：libaryX-v1.jar。

我们将多个 EAR 部署到同一个安装中，这些 EAR 由我们组织内的多个团队提供，它们处于不同的发布和预算周期。

TeamA.ear 需要 libraryX-v1.jar 并且已使用该版本进行了全面测试和认证。

TeamB.ear 需要libraryX-v2.jar，尤其是满足此团队要求的新功能，这些功能不包含在任何其他版本中。

我们如何将这两个 EAR 部署到 Wildfly？

如果 TeamA 有预算使用 librayX-v2.jar 进行测试和获得认证，那么显而易见的解决方案是在 Wildfly 中升级该模块。

当我们将libraryX-v2.jar 添加到TeamB.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 模块，因为这些可能会在服务器的未来版本中发生变化。因此，在您的情况下，您应该在 TeamA.ear 中打包 libraryX-v1.jar 以及在 TeamB.ear 中打包 libraryX-v2.jar。在这一点上，您已经干净并与 wildfly 的未来版本兼容，即使它们升级（或出于任何原因）降级此模块。

如果您需要在这两个部署之间交换 libraryX 的对象，这并不容易，因为不同的类加载器加载了不同的类。如果 libraryX 仅存在于一个版本中就那么容易，那么您可以简单地部署该库并从耳朵中引用它。但是在您的情况下，我认为只有一种方法可以使用“交换类”构建自定义库，部署它并引用它。然后获取交换对象的信息并从中创建 libraryX 对象的新实例。您需要一个固定的应用程序通信合约。