0

我正在尝试在需要时使用普通的旧 java 对象（PO​​JO）和常规类文件，并且仅在需要它们添加的功能（例如异步调用、池等）时才使用 EJB。我想知道服务器如何处理一旦项目部署在服务器上，就会出现这种行为。由于它不是由容器管理的，是否必须为每个可能调用其中一种方法的无状态会话 bean 池创建一个新实例？静态方法或状态之类的东西如何影响这个模型。

编辑：

1）我可以澄清更多。Java EE 的重点是您使用 @stateless 等注释 POJO，以便容器可以管理它。您不必声明您只需注入的无状态 bean 的新实例，并且可以调用它的类型。

2) 大多数 Java EE 教程和书籍从未将非注释类作为业务逻辑的一部分。它从来没有被提起过。如果您可以在 Java EE 项目中将它们用于您的业务逻辑并且它可以部署在服务器上，这对我来说似乎很奇怪。如果您不需要池或异步访问（容器通过 EJB 帮助管理的东西），那么您可以在 Java EE 项目中使用这些常规 POJO。

3）这导致我的问题是我如何正确地整合到项目中？我是将它们放在连接到 EAR 的 EJB 项目中还是应该放在 EAR 中？或动态网络项目。几乎没有提及或说明正确使用此类常规对象。当它被编译成 WAR 进行部署时，您在服务器上是否遇到任何问题？不是期望正确注释的 EJB、servlet 或 JSP 吗？

4

1 回答 1

2

完全不影响它。类是类，对象是对象。他们没有被管理，他们没有受到干扰，他们什么也没有发生。无论如何，它们并不特别。

静态单例就是静态单例，Java就是java。

您只需要了解容器的类加载器布局，以及它与您部署的应用程序和资源的关系。（例如，一个应用程序中的课程无法看到另一个应用程序中的课程。）大多数时候它并不重要。有时，它是，因为事情变得更加复杂。

但在大多数情况下，它只是 Java。

附加物：

一个更好的看待这个问题的方法是将你的类简单地分组到本地块中。

让我们看一个使用 EJB 的简单 Web 应用程序。

Web 应用程序部署在 WAR 工件中，并且 EJB 可以单独部署，作为容器中的单个 EJB，或者更可能的是，在 EAR 中。当您将应用程序打包到 EAR 中时，您可能也会将 WAR 捆绑在 EAR 中。因此，最终 EAR 包含您的 WAR 和您的 EJB。

现在在开发过程中，在这种情况下，您将拥有属于三个类别之一的类。

  1. 仅与 EJB 相关的类（例如会话 Bean）。

  2. 仅与 WAR 相关的类（例如 Servlet 类）。

  3. 与两者相关的类（可能是数据库实体）。

因此，将它们打包的一种简单方法是在三个 jar 文件中。您的 WAR 的 jar 文件（实际上，这是 WAR，类在 WEB-INF/classes 中），您的 EJB 的 jar 文件，以及第 3 种类型的 jar 文件，我们将其称为库。

在构建依赖方面，WAR 构建依赖于 lib，而 EJB 构建依赖于 lib。但是 WAR 和 EJB 都不相互依赖，因为它们不直接共享任何东西，只是通过第三个库 jar 间接共享。lib jar 是独立的，因为它不依赖于 WAR 或 EJB。请注意，您的 EJB 会话 Bean 接口类将进入库 jar（因为两个层都依赖它们）。

在您的耳朵里，您只需将 lib jar、WAR 和 EJB jar 与 META-INF 目录和 application.xml 文件捆绑在一起。WAR 有它自己的结构，包括 WEB-INF 和所有，EJB jar 有它的 META-INF 和 ejb-jar.xml。但值得注意的是 lib.jar 不在 WEB-INF/lib 目录中，它在 EAR 包中，因此由 EJB 和 WAR 使用容器负责的类加载器诡计共享。

这一点很重要。例如，如果您的 lib jar 中有一个简单的静态单例，那么 WAR 和 EJB 都将共享该单例，因为它们都是同一个类加载器的一部分。要使用那个 Singleton，它只是普通的 Java。那里没什么特别的。

如果 EJB 和 WAR 是分开部署的，那么他们每个人都需要自己的 lib.jar 副本，而在 Singleton 的情况下，他们不会共享它，因为每个模块都有自己的类加载器。

因此，除非有一些真正紧迫的需求，否则将所有内容捆绑到一个 EAR 中并将 EJB 层和 WAR 层视为一个单独的集成应用程序会更容易。

附录2：

人们很少谈论在 Java EE 开发中使用类，因为没有什么可谈论的，他们只是使用它们，就像在任何 Java 程序中一样。你在这里想太多了。

3 jar 习惯用法：war、ejb、lib 是我多年来使用的一种习惯，因为它分离了 3 个关注点并限制了依赖关系。客户端 -> 库 -> EJB。它还简化了构建，因为客户端通常只需要 lib jar 和 java。在 Netbeans IDE 中，这很容易管理。只需少量工作，它在其他 IDE 甚至 ant/maven 中都很简单。这不是一个巨大的负担，但保持 3 个部分相对干净。

依赖关系和 Jar 管理是任何大型 Java 项目的噩梦，当您处理不同的可部署工件时，EJB 更是如此。在我的书中，任何可以帮助减轻这种情况的东西都是一种胜利，而事实是，一个干净、独立的 lib jar 有很大帮助，尤其是你需要将该 lib 与其他代码集成和使用。例如，如果您稍后使用远程 EJB 甚至 Web 服务编写外部 GUI 客户端，则 lib jar 是客户端拥有的唯一依赖项。这个 jar 的好处远远超过了建​​立这种库所需的小麻烦。

最后，lib jar 就像您想在应用程序中使用的任何其他 jar 一样（如日志记录或任​​何其他流行的 3rd 方 jar）。

于 2011-11-11T00:47:13.507 回答