何时使用EAR以及何时应用程序应在WAR中？
我们在WebLogic服务器上有许多Spring Web应用程序，并且很好奇WAR何时应该在EAR中以及何时应该作为WAR存在。 有时，WAR需要访问常见的逻辑JAR，但我不明白为什么当这些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 for是一个WAR容器，那么您也可以使用像Tomcat或Jetty这样的vanilla servlet容器，以获得从Weblogic中获得的所有function。
我同意几乎所有的skaffman（通常）评论点。
如果你使用没有EJB的Spring，你当然可以坚持使用WAR文件。 不需要我能看到的EAR。
但是，如果您的Spring应用程序使用消息驱动的POJO，我可以看到您仍然在WebLogic上部署WAR文件以利用JMS。
如果你有EJB或JCA，可能需要EAR，但我不会说JMS要求EAR。 我已经使用了JMS并在WebLogic上部署了一个WAR文件，它运行得很好。
如果您决定使用Tomcat并在那里部署WAR，则在使用ActiveMQ时仍可以保留JMSfunction。
如果您遇到我上一个雇主所做的情况，那么将多个WAR打包到EAR中的参数可能会引人注目，其中您有一组由多个WAR使用的公共库JAR，并且该JAR集合的大小相当大。 在我们的特定情况下，每个WAR中包含通用JAR的3个WAR的总大小总计为124MB。 通过在包含的EAR中定位JAR并配置每个WAR的类路径以使用这些JAR，包含3个WAR的EAR的占用空间减少到40MB。 我认为这是一个令人信服的理由。
拥有多个共享库而不是成为EAR的令人信服的理由，因为JAR（或JAR集）总是可以部署为weblogic上的“库”，因此可以由所有WAR共享。 不是吗？
仅部署战争没有任何问题，开发人员有兴趣尽快完成任务。 这意味着他们经常承担技术债务，如果他们在一个受人尊敬的团队中，他们将清理这些债务。
然而，这会产生一个问题，当您避免EAR的复杂性时会发生什么，并通过将其添加到应用程序服务器来共享jar？ 在仅限战争的团队中，更常见的是将各种应用程序复杂性卸载到应用程序服务器。 仅仅因为它更容易实现，因为它们经常被过度分配。 我根本不会责备他们，但现在我们遇到了一个新问题。 无法使用标准应用程序服务器，必须进行系统端自定义。 实际上，Web应用程序正在遍布整个系统。 维护应用程序服务器的人现在必须也知道应用程序特定的细节…在企业环境中，这提出了一个非常明确的问题。
然后开发人员可以承担系统责任，但他们仍然需要满足最后期限。 它们也不可避免地在整个操作系统中流血，突然之间开发人员才是唯一可能的管理员。 如果管理员不知道应用程序使用系统端的是什么，它们可能会导致重大问题。 这些不清晰的线总是以指向两个方向的手指结束，未知的系统状态和团队隔离。
他们必须使用EAR吗？ 不，我是系统工程师，所以我总是说他们可以像其他商业应用程序一样部署他们自己的应用服务器。 在RPM内部，如果部署WAR与其他受支持的应用程序服务器类似，那么它们将获得WAR部署管道。 如果没有，那么RPM一体化……一旦不允许团队外部化他们的成本，那么EAR成为一个伟大的想法。