我需要你的建议/意见，如果我可以运行一个完整的Java EE 6应用程序，它使用JPA，事务服务，DI等在最小的Tomcat如果我分发Java EE 6参考SDK(一个随Glassfish附带)作为我的应用程序的一部分。
我正在尝试是否可以像人们使用Spring一样使用Java EE 6。无论我走到哪里，我都带着我测试过的应用程序和容器。
如果可行的话，你认为这种方法有什么问题吗?当然，我理解这种做法不符合Java EE规范的愿景，但我觉得有时即使在所有的承诺之后，在将应用程序从一个应用服务器移植到另一个应用服务器时，事情可能会变得更糟。
感谢大家花时间阅读和回复。
我理解这种做法与创建Java EE规范的愿景不一致
我不完全确定这是完全正确的。当然，Java EE定义的主要内容是明确的概要文件，这些概要文件需要一组特定的技术才能全部可用。这有一个很大的好处，即针对Java EE的应用程序或库可以假设像Bean验证和CDI这样的技术就在那里。
但是另一方面，几乎所有组成Java EE的子规范也可以在Java EE之外单独使用。在许多规范(例如JPA)中，它甚至明确定义了它应该如何在Java SE中工作(在这种情况下，Tomcat被视为Java SE)。在其他一些情况下(例如CDI)，它目前是在Java SE中工作的特定实现(例如Weld)的属性。
其他一些规范(例如JSF)的经验法则是，它也应该在Servlet规范上工作，该规范的版本比引入该规范的Java EE的Servlet规范版本少一个版本。例如，JSF 2.0是Java EE 6的一部分，它有Servlet 3.0，但它也必须与Servlet 2.5一起工作。据我所知，这样做并不是为了让旧的Java EE服务器只升级JSF，而是主要为运行旧的Tomcat版本的人。
与Java SE/Tomcat的所有这些兼容性都是由创建Java EE规范的愿景并实际编写和实现该规范的人完成的。
我正在尝试是否可以像人们使用Spring一样使用Java EE 6。
这里没有明确的答案，但是您可以通过"简单地"将所有实现jar文件添加到WEB-INF/lib目录(如果有war)而取得相当大的进展。例如，用于CDI的Weld jar，用于JPA的Hibernate jar，用于JSF的Mojarra jar，用于EJB的OpenEJB，等等。
这种方法的问题是，您将负责确保所有这些jar一起工作没有问题。
这些技术在一起工作可能也不如在Java EE的开箱即用的"发行版"中工作那么好;这意味着注入可能不能在你期望它工作的所有工件中工作，或者你必须提供额外的配置(例如，告诉Hibernate JTA事务管理器是什么，或者配置一个过滤器来根据请求激活CDI，另一个过滤器来激活JAX-RS，等等)。
另一个问题是，许多Java EE技术做某种注释扫描。在Java EE实现中，这可以一次全局地完成，但缺乏任何特定的标准服务，每种技术都必须在"Java SE模式"下单独完成。这意味着相同的jar将被一遍又一遍地扫描。同样不好的是，根据您确切使用的实现，您最终可能会在WEB-INF/lib中添加许多额外的jar。这些也将被扫描以进行注释。在Java EE实现中，每次部署只扫描应用程序jar。
最后，一些Java EE的东西不能单独使用，例如JASPIC，据我所知，JACC和JCA不能作为独立实现。
您只需使用TomEE即可http://tomee.apache.org/
我不是开发人员，但如果我是正确的，完整的Java EE堆栈不能在Tomcat上运行，因为它只是一个Servlet容器，而不是像JBoss或WebLogic那样的应用服务器。