Understanding J2EE Class Loading

Java Class Loading Concepts The following two basic principles will always apply: o Each class retains an association with the class loader that loaded it. The getClassLoader() method of java.lang.Class returns the class loader that loaded the class, which cannot be changed after the class is loaded. This is the class loader that will be used if the class attempts to load classes by name. o If the same class is loaded by two class loaders, classes loaded by the two class loaders will not be type compatible (although serialization will work). The documentation of the java.lang.ClassLoader class further defines the following behavior for class loaders: o Class loaders are hierarchical. When a class loader is asked to load a class, it first asks its parent class loader to try to load the class. Only if the parent (and parent's ancestors) cannot load the class, will the original classloader attempt to load the class. The top of the class loader hierarchy is the bootstrap loader built into the JVM, which loads java.lang.Object(). o Although a class loader can see classes loaded by its parent(s), it cannot see classes loaded by its children. Class Loading in J2EE J2EE servers use multiple class loaders, largely because this allows dynamic application reloading. Clearly we don't want to reload all the application server's own classes on redeploying an application. This would mean that the application server would always need to be restarted. So application servers use different class loaders for application code to those they use for their own standard libraries, for example. Typically one or more new class loaders will be created for each application deployed on a server. However, multiple class loaders are not usually used for different application-specific classes in the same application unless we use EJB (JSP pages may be given a separate class loader, but this doesn't usually affect application code). In an EAR, the EJB class loader is often the parent of the WAR class loader. Orion and WebLogic, for example, both use this approach. This is a natural implementation approach, as WARs will typically access EJBs (and therefore need to be able to see at least EJB client classes), while EJBs do not access web components. In this diagram the class loader hierarchy is represented by enclosing boxes. The parent-child relationship is represented by an enclosing box: Assuming standard J2SE hierarchical class loading behavior, such a hierarchy will mean that any class can access classes in boxes that enclose its class loader. However, classes associated with the outer boxes cannot load classes in the inner boxes. Thus web application classes can see classes deployed in the application's EJBs and system classes. However, EJB classes cannot see web application classes, and classes installed at server-wide level cannot see any application-specific classes. Class Loading in Integrated Enterprise Applications Thus there are two basic problems relating to J2EE class loading, in the common case where EJB and web modules are included in the same enterprise application: o Where do we hold the definitions of classes used in both EJBs and web applications? o How do we ensure that two class loaders don't end up holding independent versions of the same class, resulting in class cast exceptions? The Servlet 2.3 Specification's Class Loading Recommendations The Servlet 2.3 specification (9.7.2) states that "It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs". This clearly conflicts with the standard J2SE class loading behavior, as described in the Javadoc for the java.lang.ClassLoader class. As the WAR class loader must be a dynamic class loader, it must be the child of another class loader provided by the application server. Hence the Servlet 2.3 recommendation is the opposite of normal Java 2 class loading behavior, which clearly states that classes will be loaded from the child class loader (in this case the WAR class loader) only if they cannot be resolved by the ancestor class loaders. The Java 1.3 Extension Mechanism Architecture in J2EE Changes in J2SE 1.3 make it possible for JAR files to specify dependencies on other JAR files, by specifying a space-separated list of relative file paths in a Class-Path header in their /META-INF/MANIFEST.MF file. Class-Path: Iog4j-1.2.jar 121-core.jar 121-ejbimpl.jar 121-jdbc.jar This declares that the application-specific classes in the ticket-ejb.jar file depend on four infrastructure JARs, meaning that the EJBJAR file doesn't need to include any third party classes. These paths are relative. All these JAR files are included with the EJBJAR file in the root directly of the application EAR, as the following listing of the EAR's contents shows:        META-INF/        META-INF/MANIFEST.MF        META-INF/application.xml        121-core.jar        i21-ejbimpl. jar        121-jdbc.jar        ticket-ejb.jar        ticket.war        Iog4j-1.2.jar how to enable WAR manifest classpaths on Oracle 9iAS Release 2. IBM documentation, WebSphere 4.0 supports manifest classpaths for WAR filesM above links recommends using this when WARs and EJBs reference the same classes. Orion and Oracle will also load manifest classpaths in EARs by default. JBoss/Jetty does not appear to respect manifest classpaths in WARs I haven't relied on this non-portable feature in packaging the sample application. The J2EE Reference Implementation also ignores manifest classpaths in WARs. BEA discussing the use of manifest classpath Thread Context Class Loader getContextClassLoader() method on java.util.Thread. o Class.forName (classname): Will use the class loader of the helper class: in this case, the EJB class loader. This means that, if the EJB class loader is the parent of the WAR class loader, the helper will never be able to load classes in the WAR by name. o Class.forName(classname, true, Thread.currentThread().getContextClassLoader()): Will use the current container's class loader. This means that the helper will behave differently wherever it is running. If the EJB class loader is the parent of the WAR class loader, when the helper is used in the EJB container, it will only be able to load EJB classes and classes loaded by higher class loaders. If the helper is used in the WAR, it will be able to load WAR classes as well.