Web服务器/容器如何处理与EJB和实体等其他类有关的POJO？ [英] How does a web server/container treat a POJO in respect to other classes like EJB's and Entities?

问题描述

我想在需要的时候使用普通的老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？

解决方案

根本不影响它。类是类，对象是对象。他们没有管理，他们没有干扰，没有发生任何事情。他们不是特别的。

静态单身是静态单身人士，Java是java。

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

但是绝大多数情况下，这只是Java。

附录：

更好的方法是将您的课程简单地分组到本地区块。

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

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文件以及第三种类型的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包中，因此由容器负责的类装载器chicanery由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中都很简单。这不是一个巨大的负担，而是保持3个部分相对干净。

依赖关系和Jar管理是任何大型Java项目的噩梦，当您使用EJB处理不同的可部署工件。任何可以帮助缓解这一点的事情都是一场胜利，在我的书和事实中，一个干净，独立的lib jar可以帮助很多，特别是你需要将其与其他代码整合在一起使用。例如，如果您以后使用远程EJB或甚至Web服务编写外部GUI客户端，则该lib jar是客户端唯一的依赖关系。这个jar的优点远远超过了设置这种库所需的轻微的痛苦。

最后，lib jar只是一个像任何其他jar一样的jar '想要在您的应用程序中使用（如日志记录或任​​何其他受欢迎的第三方jar）。

I'm trying to use plain old java objects(POJO)'s and regular class files where needed and only use EJBs when I need the functionality that they add such as asynchronous calls, pooling, etc. I'm wondering how the server treats this behavior once the project is deployed on a server. Since it is not managed by the container does a new instance have to be created for every stateless session bean pooled that might call one of it's methods? How do things like static methods or state affect this model.

Edit:

1) I can clarify more. The point of Java EE is that you annotate a POJO with @stateless etc so that a container can manage it. You don't have to declare a new instance of a stateless bean you just inject and can make calls to it's type.

2) Most Java EE tutorials and books never mention non annotated classes as a part of your business logic. It's never brought up. This seems strange to me if you can use them in Java EE projects for your business logic and it can get deployed on a server. If you don't need pooling or asynchronous access--the things that a container helps manager through an EJB then you can use theses regular POJO's in your Java EE project.

3) that leads me to my question which is how do I incorporate properly into a project? Do I put them in the EJB project that's connected to an EAR or should they go in the EAR? or Dynamic web project. There is almost no mention or instruction on proper use of regular objects like this. When it gets compiled into a WAR for deployment are there any issues you run into on the server? Isn't it expecting properly annotated EJBs, servlets or JSP?

解决方案

The don't affect it at all. Classes are classes, objects are objects. They're no managed, they're not interfered with, nothing happens to them. They're not special is any way.

Static singletons are static singletons, Java is java.

All you need to be aware of is the classloader layout of your container, and how it relates to your deployed applications and resources. (Classes in one app can't see classes in another app, for example.) Most of the time it's not really important. Sometimes, it is, as things get more complicated.

But for the most part, it's just Java.

Addenda:

A better way to look at this is to simply group your classes up in to blocks of locality.

Let's take a simple web app that uses EJBs.

The web app is deployed in a WAR artifact, and the EJBs can be deployed separately, as individual EJBs in the container, or, more likely, in an EAR. When you package your application in an EAR, you will likely bundle the WAR within the EAR as well. So, in the end the EAR contains your WAR, and your EJBs.

Now during development, in this case, you're going to have classes that have are in one of three categories.

1. Classes that are relevant solely to the EJBs (for example the Session Beans).

2. Classes that are relevant solely to the WARs (such as a Servlet class).

3. Classes that are relevant to both (a database entity perhaps).

So, a simple way to package them is in three jar files. A jar file for your WAR (in fact, this is the WAR, with the classes in WEB-INF/classes), a jar file for your EJBs, and a jar file for the 3rd type, we'll call that a library.

In terms of build dependency, the WAR build depends on the lib, and the EJB build depends on the lib. But neither the WAR nor EJB depend on each other, as they don't share anything directly, only indirectly through the 3rd library jar. The lib jar is stand alone, since it doesn't have any dependency on either the WAR or EJBs. Note, your EJB Session Bean interface classes will go in to the library jar (since both tiers rely upon them).

In your ear, you simply bundle the lib jar, the WAR, and the EJB jar along with a META-INF dir and an application.xml file. The WAR has its own structure, with the WEB-INF and all, the EJB jar has its META-INF and ejb-jar.xml. But of note is the that lib.jar is NOT in the WEB-INF/lib directory, it's in the EAR bundle and thus shared by both the EJBs and the WAR using class loader chicanery that the container is responsible for.

This is important to note. For example, if you have, say, a simple static Singleton in your lib jar, then BOTH the WAR and EJBs will share that Singleton, since they're all part of the same class loader. To use that Singleton, it's just normal Java. Nothing special there.

If the EJB and WAR were deployed separately, they would EACH need there own copy of the lib.jar, and in the case of the Singleton, they would NOT share it, since each module would have it's own class loader.

So, barring some real burning need otherwise, it's easier to bundle everything in to an EAR and treat both the EJB tier and WAR tier as a single, integrated application.

Addenda 2:

People don't much talk about using classes in Java EE development because there's nothing to talk about, they just use them, like in any Java program. You're over thinking this here.

The 3 jar idiom: war, ejb, lib is one I've used over the years because it separates the 3 concerns, and limits dependencies. Client -> lib -> EJB. It also simplifies the build, since clients typically need just the lib jar and java. In the Netbeans IDE, this is trivial to manage. With minor work, it's straightforward in other IDEs or even in ant/maven. It's not a huge burden, but keeps the 3 parts relatively clean.

Dependency and Jar management is the nightmare of any large Java project, and even more so with EJB when you're dealing with the different deployable artifacts. Anything that can help mitigate that is a win, in my book, and truth is, a clean, stand alone lib jar helps a lot, especially of you need to integrate and use that lib with other code. For example, if you later write an external GUI client using Remote EJBs, or even web services, the lib jar is the only dependency that client has. The benefits of this jar far outweigh the minor pain it takes to set up this kind of library.

In the end the lib jar is just a jar like any other jar you'd want to use in your application (like logging or any other popular 3rd party jars).

这篇关于Web服务器/容器如何处理与EJB和实体等其他类有关的POJO？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！