java - Web服务器/容器相对于EJB和Entities等其他类如何对待POJO？

Question

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

编辑：

1）我可以澄清更多。 Java EE的要点是用@stateless等注释POJO，以便容器可以对其进行管理。您不必声明刚刚注入的无状态bean的新实例，就可以对其类型进行调用。

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

3）这使我想到一个问题，即我如何正确地将其纳入项目？我应该将它们放入连接到EAR的EJB项目中还是应该放入EAR？或动态Web项目。几乎没有提及或指示如何正确使用此类常规对象。将其编译为WAR进行部署时，您在服务器上是否遇到任何问题？它不期望带有正确注释的EJB，Servlet或JSP吗？

Answer 1

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

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

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

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

附加物：

更好的方法是将您的班级按地区分组。

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

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

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


仅与EJB相关的类（例如，会话Bean）。
仅与WAR相关的类（例如Servlet类）。
与两者都相关的类（也许是数据库实体）。


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

在构建依赖性方面，WAR构建依赖于lib，而EJB构建依赖于lib。但是WAR和EJB都不相互依赖，因为它们不直接共享任何东西，而仅通过第三个库jar间接共享。 lib jar是独立的，因为它与WAR或EJB都不相关。注意，您的EJB Session 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中有一个简单的静态Singleton，则WAR和EJB将共享该Singleton，因为它们都是同一类加载器的一部分。要使用该Singleton，它只是普通的Java。没什么特别的。

如果将EJB和WAR分开部署，则它们将各自需要lib.jar的副本，而对于Singleton，它们将不会共享它，因为每个模块都具有自己的类加载器。

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

附录2：

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

3 jar习惯用语：war，ejb，lib是我多年来使用的一种，因为它分离了3个问题，并限制了依赖性。客户端-> lib-> EJB。由于客户端通常只需要lib jar和java，因此它也简化了构建。在Netbeans IDE中，这很容易管理。只需少量的工作，它在其他IDE甚至在ant / maven中都非常简单。这不是一个很大的负担，但可以保持三个部分相对清洁。

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

最后，lib jar只是一个与您要在应用程序中使用的任何其他jar一样的jar（例如日志记录或任​​何其他流行的3rd party jar）。