我们有许多 Spring Web 应用程序要在 WebLogic 服务器上创建，并且对 WAR 何时应该进入 EAR 以及它们何时应该作为 WAR 存在感到好奇。有时，WAR 需要访问公共逻辑 JAR，但我不明白为什么当它们可以被打包到 WAR 中时，它们为什么需要进入 EAR。
据我了解，如果 EAR 中有多个 WAR，并且您需要修改其中一个 WAR，则需要重新部署整个 EAR 以更新服务器。这将导致所有 WAR 反弹。但是，如果它们不在 EAR 中，我可以只更新一个 WAR，它将是唯一一个反弹的。
单独使用 100 个不同的 WAR 文件并使用打包的 JAR 和共享库（使用 WebLogic）有什么问题？
感谢您的任何见解！
如果您只有 WAR 文件，那么 EAR 的用处有限，只能用作 WAR 的部署容器。您可以通过以这种方式在 WAR 之间共享 JAR 来节省一点臃肿，但这本身并没有太大的吸引力。
然而，在处理使用 WAR、EJB、JMS、JCA 资源等的完整 JavaEE/J2EE 应用程序时，EAR 是必不可少的。这类应用程序的组件之间的交互和依赖关系在 EAR 中更容易管理。
但是，如果您使用 Weblogic 的目的只是一个 WAR 容器，那么您不妨使用 Tomcat 或 Jetty 之类的 vanilla servlet 容器，以实现您从 Weblogic 中获得的所有功能用途。
我同意几乎所有 skaffman（通常）在评论中的观点。
如果您使用没有 EJB 的 Spring，当然可以坚持使用 WAR 文件。不需要我能看到的 EAR。
但是，如果您的 Spring 应用程序使用消息驱动的 POJO，我可以看到您仍将在 WebLogic 上部署 WAR 文件以利用 JMS。
如果您有 EJB 或 JCA，则 EAR 可能是必需的，但我不会说 JMS 要求使用 EAR。我使用了 JMS 并在 WebLogic 上部署了一个 WAR 文件，它工作得很好。
如果您决定使用 Tomcat 并在那里部署 WAR，那么如果您使用 ActiveMQ，您仍然可以保留 JMS 功能。
将多个 WAR 打包到一个 EAR 中的论点可能会令人信服，如果您遇到我上一个雇主所做的情况，您有一组通用的库 JAR 供多个 WAR 使用，并且该 JAR 集合的大小相当可观. 在我们的特定情况下，3 个 WAR 的总大小以及将公共 JAR 打包到每个 WAR 中的总大小为 124MB。通过在包含 EAR 中定位 JAR 并配置每个 WAR 的类路径以使用这些 JAR，包含 3 个 WAR 的 EAR 的占用空间减少到 40MB。我认为这是一个令人信服的理由。
拥有多个共享库不应该成为选择 EAR 的令人信服的理由，因为 JAR（或 JAR 集）始终可以部署为 weblogic 上的“库”，因此可以由所有 WAR 共享。对吗？
仅仅部署战争实际上并没有错，开发人员有兴趣尽快完成任务。这意味着他们经常会承担技术债务，如果他们在一个受人尊敬的团队中，他们会清理这些债务。
然而，这带来了一个问题，当您避免 EAR 的复杂性并通过将其添加到应用程序服务器来共享一个 jar 时会发生什么？在仅战争的团队中更常见的是，将各种应用程序复杂性卸载到应用程序服务器上。仅仅因为在他们经常过度分配的时间表中更容易实施。我一点也不怪他们，但是现在我们遇到了一个新问题。不能使用标准应用服务器，必须进行系统端定制。实际上，Web 应用程序正在整个系统中流血。维护应用程序服务器的人，现在还必须知道应用程序的具体细节……在企业环境中，这提出了一个非常明显的问题。
然后，开发人员可以承担系统责任，但他们仍然需要按时完成任务。他们不可避免地也会在整个操作系统中流血，突然之间，开发人员是唯一可能的管理员。如果管理员不知道应用程序在系统端使用什么，他们很可能会导致重大问题。这些不清楚的界线总是以两个方向的手指指向、未知的系统状态和团队孤立而告终。
那么他们必须使用EAR吗？不，我是一名系统工程师，所以我总是说他们可以像部署另一个商业应用程序一样部署自己的应用程序服务器。在 RPM 中，如果部署 WAR 与其他受支持的应用程序服务器一样，那么它们将获得 WAR 部署管道。如果没有，那么 RPM 合而为一……一旦不允许团队将成本外部化，那么 EAR 就成为一个好主意。