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:
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.