从 Java EE6 开始，可以将 EJB 放入 WAR 文件中。还有什么好的技术理由可以将它们分开吗？我正在专门寻找一些只能使用 EJB JAR 完成的事情，而我确实无法使用嵌入在 WAR 中的 EJB 完成。
有人可能会说模块化，但老实说，我发现使用单独的 JAR 文件的模块化是浪费时间，而且对于只能一起使用的东西来说，额外的管道和类路径令人头痛(如果我们稍后确实需要将其分开，那只是如果需要，可以重构为单独的 JAR)。额外的依赖项(例如 guava)是不同的，因为它们不是 EJB。
将所有内容保留在 WAR 中的另一个优点是，如果您不想，甚至不需要 EAR 文件(除了以标准方式设置上下文根之外)。 WAR 文件可以包含所有支持依赖项，例如 guava 等。
另一个可能是针对非“网络应用程序”的应用程序，这很有意义，但无论如何，我使用的大多数东西都是网络应用程序，这就是为什么我限定了“针对网络应用程序”的问题。
我不会列出 EJB 客户端应用程序及其接口(interface)。实际上，我会使用 Web 服务而不是特定的语言来处理这种形式的连接。
理论上，我可以在 EJB 中执行 Web 服务，但这并不适用于所有容器，特别是 websphere，它需要您构建一个 Web Router 项目，该项目基本上是另一个 WAR 文件。
那么还有什么好的技术理由来将它们分开吗？
最佳答案
没有技术原因，没有。我们在 EJB 3.1 的规范级别上做得非常好，引入这一点是为了使过渡尽可能顺利。
我们未能完成的一个地方是ejb-jar.xml 文件的主题。一个 Web 应用程序只能有一个 WEB-INF/ejb-jar.xml 文件。即使 WEB-INF/lib/ 下的 jar 文件中有 ejb，情况也是如此。如果这些 jar 碰巧包含 META-INF/ejb-jar.xml 文件，它们将被忽略。
这是故意的，因为 ejb-jar.xml 包含以某种“全局”方式定义事物的能力，例如默认事务属性、安全约束、默认拦截器。最终决定以某种方式合并这一切是很尴尬的。
我个人预计会听到比我们更多的提示——到目前为止，我还没有听到有人提到他们发现整个 web 应用程序只允许使用一个 ejb-jar.xml 作为限制。然而，如果人们突然开始提示，我们可以像 Servlet web-fragment.xml 一样引入一个 ejb-fragment.xml 概念，这样配置就可以打包为WEB-INF/lib/ 目录中的 jar 文件。
当然，如果您正在阅读本文并且您有偏好，请对下面的评论进行投票。
关于ejb - 我是否仍然应该在 Java EE6+ 中为 Web 应用程序创建 EJB JAR？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25232698/