ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button EJB 2

EJB 2 and J2EE Packaging, Part II


In my last article, I discussed the nature of EAR files, what they support, what they do not support, and how to configure dependency utility libraries using the manifest Class-Path: entry within a JAR file. This article intends to expand upon the discussion of J2EE packaging issues by focusing on the approaches that vendors can use for implementing EAR classloaders. Additionally, this article will point out an ambiguity that exists in the J2EE specification that allows vendors to implement EAR classloading schemes differently.

Understanding Classloading Schemes

With any application that needs to have a JSP/servlet access an EJB, the JSP/servlet needs to be able to load the classes it needs to work with the EJB. When a standalone application is deployed, it is done so in its own classloader. This means that if you deploy a Web application (WAR) and an EJB application (JAR) separately, the respective classes for each application will be loaded in different classloaders that are siblings of one another. The classes in the Web application classloader will not be visible to the classes in the other application's classloader. This creates a problem for Web applications that want to use EJBs that are deployed separately. In fact, prior to EAR files, many developers would deploy an EJB and then repackage the same EJB JAR as part of the WEB-INF\lib directory of the Web application. The same class files would exist in two different places, so that the overall application could work correctly. Gross.

EAR applications were introduced to solve this very problem. EAR files are not merely a convenient packaging format, but they provide for a special classloading scheme that allows applications within the EAR file to view the classes of other applications.

What's interesting about the J2EE 1.3 specification is that it doesn't make any specific requirements as to the structure of how an EAR classloader might work. Given this flexibility allowed by the specification, an application server vendor has an incredible amount of flexibility in deciding how classes should be loaded. For example, some questions that a vendor needs to ask before implementing an EAR classloader include:

Comment on this articleFollow-up with Tyler with your questions.
Post your comments

Also in EJB 2:

Unlocking the True Power of Entity EJBs

Stateful Session EJBs: Beasts of Burden

EJB 2 and J2EE Packaging

  • Will all classes in all applications in the EAR file be loaded by a single classloader or different classloaders?
  • Should there be any parent/child classloader relationships between different applications in the EAR file? For example, if two EJB applications depend upon log4j.jar, should the log4j.jar be loaded in a parent classloader and then the EJB applications loaded in a child classloader, so that appropriate visibility is maintained?
  • If a hierarchy of classloaders is allowed, to what degree of depth will the hierarchy be allowed to extend?
  • EJBs have inherent relationships with one another, but Web applications do not. Will EJB applications be loaded differently than Web applications, so that Web application integrity can be maintained?

The Pre-EJB 2.0 PFD2 Option

Prior to EJB 2.0 Public Final Draft 2, vendors had a lot of flexibility in choosing how to set up a classloading scheme. JSPs/servlets that needed to make use of an EJB only needed to be able to load the home interface, remote interface, common classes, and stub classes of the EJB. The common classes, such as exceptions and parameters, should be placed into a dependency JAR file and loaded as part of the manifest Class-Path: entry. This requires vendors to determine a way for a Web application that depends upon an EJB to load the home interface, remote interface, and stubs.

Please refer to Figure 1: Simple Classloading Approach for a graphical representation of a simple classloading scheme that a vendor could implement. In this model, each EAR application would be loaded by a custom EAR classloader instance. EJB applications and Web applications would each be loaded by custom classloaders that are children of the EAR classloader. In this scheme, any class file that needs to be shared by more than one application in the EAR will be loaded by the EAR classloader. Any files loaded at the EAR classloader level are automatically visible to all classes loaded by children classloaders.

Figure 1. Simple Classloading approach

In this scenario, all EJB applications are loaded by a single EJB classloader that is a child of the EAR classloader. Even if you have different EJB JAR files, they will all be loaded by the same classloader. This is done to facilitate EJB-EJB communication between EJBs in different applications, but hosted on the same virtual machine. Also in this scenario, each Web application is loaded in a different classloader to maintain class isolation. For example, if every Web application has an index.jsp, when that JSP is converted into a servlet, that servlet could have the same class name as the equivalent servlets for the index.jsps in the other Web applications. Each Web application needs to be able to load its own version of that servlet, so each Web application is isolated in its own classloader.

Pages: 1, 2

Next Pagearrow