我正在阅读Beginning Java EE 6 with GlassFish 3 ，我对打包Java EE应用程序的正确性感到困惑。
EJBs Lite可以直接在war或jar文件中进行保护。如果你需要使用完整的EJB规范（例如，远程接口，JMS，异步调用......），你必须将它打包在罐子里，而不是战争。
这是什么意思？如果我在Glassfish中部署一个打包为WAR的应用程序，它不会给我所有的Java EE服务吗？如果是这样，我错过了什么。
我理解3.1引入了一个新的配置文件EJB Lite，它旨在成为完整规范的一个子集，目标是不希望实现所有内容的实现者，并且您可以在3.1中将EJB打包并使用EJB Lite规范指定的服务。但是如果你在一个完整的规范容器中部署一个WAR，它应该像你创建一个JAR一样给你一切吗？ WAR不仅仅是JAR的另一个名称吗？区别不在于它是如何打包的，而是它实际支持的内容？
有人可以澄清一下。
答案 0 :(得分：2)
将EJB逻辑bean放入JAR文件的动机来自业务逻辑和视图逻辑之间的分离。此时，据我所知，没有必要将所有EJB打包到JAR中，然后将此JAR与WAR结合到EAR中。
但是......因为EJB应该只关注业务逻辑，所以将它们打包在一个单独的存档中是有意义的。另一方面，WAR是与向用户显示GUI相关的所有内容的存档，因此包括JSP，Facelets，图像，CSS文件和JavaScript库。 WAR文件可以在WEB-INF\classes文件夹中包含一组类，以及WEB-INF\lib中的自己的库。无论如何，WAR文件不必是文件。 WAR文件可以成为一个爆炸的WAR，基本上是一个与存档中结构相同的目录。
这是类加载器层次结构中类加载器隔离的一个关键方面。 WAR模块可以访问EJB归档（JAR）中的资源，EJB模块可以引用和访问EAR文件本身中的资源（库）。禁止使用另一个方向，特别是从EJB模块访问WAR资源。这就是设计方式，因为它可以防止开发人员 - 在压力下工作 - 混合这些问题并创建意大利面条代码。业务逻辑应该与View Logic分开，因为它可以并且应该由Java SE客户端，不同的Web模块客户端，JAX-RS或基于SOA的解决方案重用。如果业务逻辑在JSF或Servlet之间存在任何依赖关系，则在Java SE桌面解决方案中使用它们是不可能的。
因此，拥有一个包含许多JAR和WAR文件的EJB归档结构可能没有必要，但这是一种最佳实践，并且应该谨慎和有意识地违反该规则。