对耳朵和战争使用相同的类加载器答案

【问题标题】：Using same classloader for ear and war对耳朵和战争使用相同的类加载器
【发布时间】：2019-09-23 21:33:00
【问题描述】：

目前，我们有 100 多个 wars/ejb 捆绑在一个耳朵中。因为我们不想总是部署它们，所以我们想拆分部署在：

ejb-ear
- ejb1.jar
- entities.jar
first.war
second.war
third.war

如何从部署的战争中简单地查找 ejb1.jar - 如果可能的话。

我阅读了以下文档，但我不知道如何使其工作。

我可以在耳朵中查找 ejb，但无法将其投射到接口。这似乎是正确的，因为这是不同的类加载器。

见： Java EE: Proxy cannot be cast to Local Interface, maybe classloading issue?

【问题讨论】：

你使用什么应用服务器？
@mentallurg 我们想使用 wildfly > 10
1) 您的 WAR 不在 EAR 中，您想在 EAR 上独立部署每个 WAR？这样您就有 100 多个应用程序。正确的？ 2（在每个 WAR 中，您希望使用其实现封装在 EAR 中的 EJB。对吗？
1) 我们的 WAR 不在耳内，它们应该独立部署。我们有很多战争。（大约 100 个） 2) 是的，有些 WAR 需要注入一些 EAR 内部的 Bean

标签： java jakarta-ee wildfly classloader war

【解决方案1】：

要么使用导致编组和解组（性能）的远程接口，要么通过添加 deployment.MY_DEPLOYMENT_NAME 将模块依赖项从 WAR 引入 EAR，例如到jboss-deployment-structure.xml。然后您使用相同的类加载器，但您的 WAR 可能会在您重新部署 EAR 时脱机。

参见例如https://access.redhat.com/documentation/en-us/jboss_enterprise_application_platform/6.1/html/development_guide/chap-Class_Loading_and_Modules#Dynamic_Module_Naming1

用于文档。

【讨论】：

我创建了一个jboss-deployment-structure.xml，它看起来像：<jboss-deployment-structure> <deployment> <dependencies> <module name="deployment.ejb-ear.ear"/> </dependencies> </deployment> </jboss-deployment-structure>，但无法将 ejb 加载到耳朵内。编辑：我试图从耳朵里注入豆子：@Inject private Instance<TestingInterface> instances;

【解决方案2】：

可以有不同的解决方案。

1) 仅将那些使用 EJB 的 WAR 打包到 EAR 中。然后，您可以通过本地接口使用 EJB。所有其他 WAR 仍然可以独立部署，并且它们不需要与 EAR 相同的类加载器。

2) 使用远程 EJB。将它们使用的 EJB 的接口打包到 WAR 中。同样，不需要在同一个类加载器中。如果你担心远程 EJB 的性能，那么首先测试一下真正的性能。 Jboss 开发人员对性能进行了很多优化。例如read here，他们优化了 EJB 调用

... 避免进行不必要的服务器端通信通常会涉及网络调用、编组/解组等。

3) 分析 WAR 和 EJB 的依赖关系，以及 EJB 之间的依赖关系。尝试识别 4-5 个 EJB 和 WAR 组或“集群”，它们彼此非常接近，并且只使用其他组中的少数 EJB，甚至不使用其他组中的 EJB。然后将这些组打包到单独的 EAR 中。例如，您可以：

一个主 EAR，提供 20 个 EJB，负责用户和权限管理
一个带有 10 个 EJB 和 5 个 WAR 的 EAR 用于产品管理
一个带有 20 个 EJB 和 30 个 WAR 的 EAR 用于订单管理
一个带有 ... EJB 和 ... WAR 的 EAR 用于装运管理

然后在大多数情况下，您将只部署其中一个 EAR，因此您的部署时间将快 4-5 倍。

【讨论】：

问题在于，所有 WAR 都使用了一些 ejb。目前我们有一个（非常）大的 EAR，我们想把它分成一个较小的 EAR 和 WAR。我们考虑了想法 2)，但随后我们需要捆绑 EJB（接口）所需的所有实体。如果每 >100Wars 捆绑相同的实体，那将是一个巨大的过载，不是吗？
通常接口很少改变。如果 EJB 发生更改，主要是更改其实现，例如EJB 更改中有新的需求和业务逻辑。因此，您经常会部署带有 EJB 实现的 EAR。但在大多数情况下，不需要也重新部署 WAR，因为接口没有改变。这就是为什么我不明白您为什么要谈论重新部署 WAR。
在我重新部署 ejb 的同时，我从未说过重新部署战争。
好的，那我误解了你的问题。那么为什么不使用远程 EJB 呢？正如我上面所说的（参见变体 2），JBos 具有优化的性能。因此，如果 WAR 和 EAR 部署在同一台服务器上，您不会看到本地和远程情况之间有太大区别。为什么不考虑远程 EJB？
例如，当使用GlobalEJB（在每个 WAR 中使用）时，我们需要捆绑每个 WAR 中的所有实体。我可以理解这个错误，但这意味着每 100 个实体将在每个部署（类加载器）中加载。这可能会导致更大的类加载器和更大的内存使用。似乎不可能对所有部署都使用一个类加载器，所以我不能将 WAR 依赖项放到要提供的实体上。我想我会测试解决方案 3