如果我可以在最小的 Tomcat 上运行完整的 Java EE 6 应用程序（使用 JPA、事务服务、DI 等），如果我分发 Java EE 6 参考 SDK（Glassfish 附带的一个），我需要您的建议/意见作为我申请的一部分。
我正在尝试是否可以像人们使用 Spring 一样使用 Java EE 6。无论我走到哪里，我都会带着我测试过的应用程序和容器。
如果可行，您认为这种方法有什么问题吗？当然，我知道这种做法与创建 Java EE 规范的愿景不相符，但我有时觉得即使在所有承诺之后，将应用程序从应用程序服务器移植到另一个应用程序时情况可能会变得更糟。
感谢大家花时间阅读和回复。
【问题讨论】：
标签： jakarta-ee tomcat jpa transactions
我了解这种做法与创建 Java EE 规范的愿景不一致
我不完全确定情况是否完全如此。当然，Java EE 定义的主要内容是清晰的配置文件，需要一组特定的技术才能全部可用。这具有很大的优势，即针对 Java EE 的应用程序或库可以假设诸如 Bean Validation 和 CDI 之类的技术（仅举出两种技术）就在那里。
但另一方面，几乎所有组成 Java EE 的子规范也可以在 Java EE 之外单独使用。在许多规范（例如 JPA）中，它甚至明确定义了它应该如何在 Java SE 中工作（在这种情况下，Tomcat 算作 Java SE）。在其他一些情况下（例如 CDI），它目前是在 Java SE 中工作的特定实现（例如 Weld）的属性。
根据经验，其他一些规范（例如 JSF）也应该适用于比引入该规范版本的 Java EE 的 Servlet 规范版本低一个版本的 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 目录中来获得相当远的结果。例如。用于 CDI 的 Weld jar、用于 JPA 的 Hibernate jar、用于 JSF 的 Mojarra jar、用于 EJB 的 OpenEJB 等。
这种方法的问题在于 -YOU- 将负责确保所有这些 jar 一起工作而不会出现问题。
这些技术协同工作的效果可能不如它们在 Java EE 的开箱即用“发行版”中工作那么好；这意味着注入可能不适用于您希望它工作的所有工件，或者您可能必须提供额外的配置（例如，告诉 Hibernate JTA 事务管理器是什么，或者配置过滤器以根据请求激活 CDI 和另一个过滤器以激活 JAX-RS 等）。
还有一个问题是，许多 Java EE 技术都会进行某种注解扫描。在 Java EE 实现中，这可以在全球范围内一次性完成，但缺乏任何特定的标准服务，每种技术都必须在“Java SE 模式”下单独完成。这意味着将一遍又一遍地扫描相同的罐子。这里也不好的是，根据您确切使用的实现，您最终可能会在 WEB-INF/lib 中得到很多额外的 jar。这些也将被扫描以获取注释。在 Java EE 实现中，每次部署只会扫描应用程序 jar。
最后，一些 Java EE 的东西不能单独使用，例如JASPIC 以及据我所知 JACC 和 JCA 不能作为独立实现使用。
【讨论】：
您只需使用 TomEE http://tomee.apache.org/
【讨论】：
我不是开发人员，但如果我是正确的，完整的 Java EE 堆栈不能在 Tomcat 上运行，因为它只是一个 Servlet 容器，而不是像 JBoss 或 WebLogic 那样的应用程序服务器。
【讨论】：