Section A.2. Class Loading in the J2EE

A.2. Class Loading in the J2EE

Class Loading is one of the least understood aspects of J2EE deployment. Although not officially part of the J2EE specification, most application servers use a strategy similar to the ClassLoader hierarchy in Figure A-2 to support J2EE component deployment.

The J2EE-based ClassLoaders work as follows:

• The EAR ClassLoader loads the classes from JARs contained in the EAR file.

• The EJB ClassLoader loads EJBs and related classes that reside in the EJB JAR file.

• The WAR ClassLoader loads the web-specific classes and JARs in the WAR file's WEB-INF/{class,lib} directories.

Because each ClassLoader has no access to the classes loaded by its children or siblings, the classes in the WAR file are not visible to EJBs. Of course EJBs shouldn't try to reference things in the WAR in the first place because it is poor architecture. Each layer should not know about the invoking layer, and you can't assume that a web-based presentation layer will always be in your application.

Figure A-2. Generic J2EE Application Server Class Loader Hierarchy

The J2EE specification is vague concerning the deployment order of the J2EE modules. Many application servers deploy the JARs and classes in the EAR, and then the classes in the EJB JAR, and finally, the classes and JARs in the WAR. In the JAW Motors application, the Common JAR strategy works because the EAR contains the Common JAR, so the application-specific dependency classes and the third party utility JARs get deployed first, then the EJBs in the EJB JAR are loaded, and the web components from the WARwhich depend on the EJBs and common classes and JARsdeploy last.

Here is a practical example that uses the class-loading scenario from Figure A-3. In the JAW Motors application, a JSP invokes a Servlet, which in turn uses an EJB; both the Servlet and the EJB use Log4J. Since the JSP and Servlet are packaged in the WAR, the WAR ClassLoader finds and loads the JSP and Servlet. When the Servlet instantiates the EJB, the WAR ClassLoader cannot find the EJB, so WAR ClassLoader defers to its parentthe EJB ClassLoader. The EJB JAR contains the EJB, so the EJB ClassLoader finds and loads the EJB on behalf of the WAR ClassLoader. When the Servlet instantiates the Log4J Logger to log messages, neither the WAR ClassLoader nor the EJB ClassLoader can find the Log4J JAR, so they delegate to their parent, the EAR ClassLoader. Since The Common JAR contains the Log4J JAR, the EAR ClassLoader finds and loads the Log4J Logger on behalf of the child ClassLoaders.