Introducing the WebLogic Server ClassLoaders

This section introduces a much overlooked and frequently misunderstood topic on how WebLogic Server uses Java ClassLoaders to load system resources and, most importantly, your application resource files. Understanding the role that WebLogic Server ClassLoaders play in the course of deploying your J2EE applications to WebLogic Server enables you to not only package your J2EE application classes correctly, but also to leverage WebLogic Server's capability to provide such features as application partitioning, dynamic redeployment, and undeployment.

What Are Java ClassLoaders?

A ClassLoader is a Java class that's responsible for locating and loading system and application Java classes into the Java Virtual Machine (JVM) as they're required at runtime. Loading a class represents reading the bytecode implementation of the class and loading it into the JVM runtime. Multiple ClassLoaders are associated with a JVM, with each ClassLoader assigned to a classpath that serves as the search path for locating and loading the required classes into memory.

The ClassLoaders provided with a JVM runtime are known as System ClassLoaders, and are typically arranged in a parent-child hierarchy. For example, when you start the JVM in Java Development Kit (JDK) 1.3, three System ClassLoaders are created by default with the following hierarchy:

• At the very top of the hierarchy is the bootstrap ClassLoader, which is created by the JVM and loads all the JDK internal classes including classes of the core API, such as java.lang , java.io , and so on.

• The bootstrap ClassLoader is a parent to the extensions ClassLoader, which loads classes in the extension directory of the JDK, as defined by the value of the java.ext.dirs Java system property. The classes in the extension directory are used to extend the functionality of the core platform and include both native code libraries and Java classes.

  Note

  All classes found in the extension directory must be self-contained and can refer to only classes in the extension directory or JDK classes.

  
  

• The extensions ClassLoader is a parent to the system classpath ClassLoader, which loads the classes from the classpath specified by the JVM via the CLASSPATH environment variable or the -classpath Java option.

Note

Application-specific ClassLoaders, which are discussed in the next section, are children to the system ClassLoader.

To load a class, ClassLoaders use a delegation model. For example, if a ClassLoader is requested to load a class, the ClassLoader implementation first verifies whether a specific class has already been loaded in memory instead of always reading the class from its classpath. If the class is not found in memory, the parent ClassLoader is typically requested to fulfill the request. The parent ClassLoader in turn asks its parent to fulfill the request. This goes upward until the request reaches the top of the hierarchy. If the topmost ClassLoader cannot fulfill the request, the request for loading the class traverses down the hierarchy to the initial ClassLoader that made the request. If this ClassLoader cannot fulfill the request to load the class, the ClassLoader throws a ClassNotFoundException . Also, if a class exists in both the parent and child ClassLoaders, the parent version is loaded.

Note

Depending on the ClassLoader implementation, a ClassLoader might attempt to resolve a class by checking its parent before or after checking itself.

The relationship among ClassLoaders signifies that classes loaded by a particular ClassLoader can reference other classes only as long as those other classes can be loaded by the same ClassLoader or any of its ancestors . For this reason, a ClassLoader has no visibility into classes loaded by its children or sibling ClassLoaders. A class of a specific type can be loaded by two sibling ClassLoaders. However, in that case, each ClassLoader has its own version of the class that will not be type-compatible with the other.

J2EE Application Classloading in WebLogic Server

WebLogic Server provides application ClassLoaders to load classes in your applications including servlets, Enterprise JavaBeans, JavaServer Pages (JSP) files, JavaBeans, and other supporting class libraries. They also enable WebLogic Server to provide such features as application partitioning, hot deployment, hot redeployment, and hot undeployment of applications.

Classloading in the context of WebLogic Server is centered on the concept of an application. For this reason, before discussing the topic of classloading specific to WebLogic Server, it's essential that you understand what WebLogic Server considers to be an application.

An application in WebLogic Server can consist of any of the following components :

• Web Applications: JSPs, servlets, HTML pages, images, and related files. These files are packaged into a JAR file with a .war extension.

• Enterprise JavaBeans: Entity, session, and message-driven beans. These are packaged into a JAR file with a .jar extension.

• Connector Archives: Connector components. These are packaged into a JAR file with a .rar extension.

• Enterprise Archives: All or any of the preceding three components are packaged into a JAR file with an .ear extension.

Each of these packaged components also contains XML deployment descriptors, which instruct the hosting Web or EJB container of WebLogic Server on how to deploy the respective applications. The packaging of applications and deployment descriptor specifics are discussed in detail in the "Packaging Applications Targeted for WebLogic Server" section.

With this brief overview on the types of WebLogic Server applications, we can now look at the classloading mechanism used by WebLogic Server to load these applications.

Understanding the WebLogic Server ClassLoader Hierarchy

The Java ClassLoaders that are part of the JDK do not have any standard mechanism for undeploying or unloading a set of classes, or even for loading new versions of classes. A technique that all application servers use to get around this constraint is to create an application-specific ClassLoader as a child of the system classpath ClassLoader. Hence, when an application is deployed to WebLogic Server, the server creates a set of ClassLoaders to load that specific application. These ClassLoaders are arranged in a hierarchical fashion, and every application receives its own ClassLoader hierarchy. Because these application ClassLoaders can see only their parent ClassLoader (system classpath), WebLogic Server is able to host multiple isolated applications within the same JVM.

Note

If a class is in the system classpath, it cannot be modified in any way while WebLogic Server is running.

When an enterprise (EAR) application is deployed to WebLogic Server, it automatically creates two new ClassLoaders: one for EJBs and one for Web applications. The EJB ClassLoader, also known as the base ClassLoader, is a child of the system ClassLoader and the Web application ClassLoader is a child of the base ClassLoader.

The base application ClassLoader is created by WebLogic Server to load all the classes in the EJB JAR files contained in the application archive file ( .ear ). According to the Servlet specification, Web applications must be loaded on their own ClassLoader, which allows each Web application to have its own classpath and also guarantees that there will be no class name conflicts between the Web applications. For this reason, the JSPs and servlets from the Web application WAR file are loaded by the Web application ClassLoader.

Because JSPs and servlets typically make use of the EJB interfaces, rather than vice versa, this arrangement allows the JSPs and servlets to find the EJB interfaces as they're loaded by the parent ClassLoader. This application ClassLoader hierarchy makes it easier to redeploy the JSPs and servlets (Web tier) classes without redeploying the EJB JAR file (EJB tier). During the development phase, changes in the Web tier are generally more common than changes to the EJB tier.

To illustrate this classloading hierarchy, suppose that an EAR file called application1.ear is deployed to WebLogic Server. This application1.ear contains an EJB in a JAR file: ejb1.jar . The EAR also contains a Web application, webApp1.war , which has JSPs and servlets that call the EJB remote methods . The classloading hierarchy for this EAR is shown in Figure 27.1.

Figure 27.1. A classloading hierarchy for a typical J2EE application ” application1.ear .

Now, if you have two applications, application1.ear and application2.ear , the classloading hierarchy would be as shown in Figure 27.2.

Figure 27.2. A classloading hierarchy for two J2EE applications ” application1.ear and application2.ear .

In this hierarchy, the application ClassLoaders for application1.ear and application2.ear are children to the system ClassLoader and are therefore siblings of each other. So, if JSPs and servlets within webapp2.war were to call remote methods of an EJB in EJB1.jar , you would be required to package the home and remote interfaces of that EJB within the webapp2.war file. This is because classes have visibility into only their parent ClassLoader, not their children or sibling ClassLoaders.

If you deploy the WAR and JAR files separately, WebLogic Server creates sibling ClassLoaders for them, respectively. The Web Application ClassLoader loads classes from the WEB-INF\lib and WEB-INF\classes directories of the Web application. The servlets and JSPs are loaded in their own ClassLoaders, which are children to the parent Web application ClassLoader. This allows WebLogic Server to reload the JSPs and servlets individually, instead of reloading the entire Web application.

Making Use of the PreferWebInfClasses Element

WebLogic Server provides a parameter named PreferWebInfClasses that enables you to override the default classloading behavior with respect to Web applications. By default, this parameter is set to false, which implies that a class loaded by the system or the application ClassLoader will have preference over one loaded by the WebApplication ClassLoader. This is consistent with the ClassLoader hierarchy explained previously. However, some users might want to override this behavior; for example, while loading XML parser classes in their Web applications.

In these cases, setting the PreferWebInfClasses parameter to true loads the classes located in the WEB-INF\classes directory in preference to the ones loaded by the WebApplication's parent ClassLoaders. Because this element is part of the WebAppComponentMBean , you can set its value for a Web application through the Administration Console. However, you should be careful while casting these classes, because it's generally not a good idea to excessively mix instances of classes loaded from different ClassLoaders.

Application Classloading Optimization in WebLogic Server

The two common parameter-passing models in Java are pass by value and pass by reference. In the pass by value model, the parameters and the return values are copied for each method call. In the pass by reference model, the actual reference or the pointer to the object is passed when a method is called. The called method operates on the reference and therefore modifies the actual object. Because no copying of parameters is involved, the pass by reference model is more performance-based than the pass by value model.

WebLogic Server uses this efficient call by reference parameter-passing model to optimize performance when the caller to a method and the method being called are in the same application. For example, when a JSP/servlet class calls a remote method on an EJB within the same application, WebLogic Server uses the call by reference model.

By default, when the caller and the method being called are in different JVMs, or even in different applications in the same JVM, WebLogic Server uses the pass by value mechanism, which involves RMI marshalling and unmarshalling.

Keeping this optimization in mind, it's always a good practice to package the WAR and JAR files together into an EAR file ”that is, package them into one application. This has two advantages:

• As explained earlier, a ClassLoader hierarchy is created such that the JSPs and servlets from the Web application can find the EJB remote interfaces (loaded in the application ClassLoader). This prohibits the need to copy and package the EJB's home and remote interfaces within the WAR file.

• When the WAR file and the EJB JAR file it calls into are in the same application, WebLogic Server can make use of the call by reference optimization.

Best Practices for Packaging Shared Utility Classes

In practice, J2EE applications make use of utility classes and third-party packages. There are some best practices you can follow while packaging these applications so that the applications are partitioned well and can be redeployed without dependencies:

• If you have to use utility classes that you would need in several applications in WebLogic Server, you must package them as a JAR file with each application. This is the recommended method because you can reload the utility classes in case they change, without redeploying the complete application.

• You might also add the shared utility classes to the system classpath of WebLogic Server. The classes are loaded by the system classpath ClassLoader, and are therefore available to all the application ClassLoaders, which are its children. However, unless you restart WebLogic Server, this doesn't enable you to reload the utility classes if they're modified.

• If you need to bundle resource adapter classes with your EJBs or Web applications, you must bundle them within the corresponding application archive.

Making Use of the Manifest Class-Path

While developing J2EE applications, you might require some utility archives or third-party libraries to be bundled along with your application. The J2EE specification allows the use of a manifest file entry named Class-Path to specify the supporting JARs as a part of the J2EE application.

To include the utility classes using the Class-Path entry, you should create a manifest file named MANIFEST.MF that references the utility JAR files. The manifest file must be located in the META-INF directory of your application archive and should contain the following entries:

 Manifest-version: 1.0 Class-Path: utility1.jar,utility2.jar,utility3.jar 

The first line of the manifest file must always contain the Manifest-version , which should be followed by a new line character. On the next line, you can specify the Class-Path attribute with the utility JARs you want to bundle along with the application.

The Class-Path entry refers to other archive files relative to the current archive. Thus, multiple Web application WAR files and an EJB JAR file can share a common JAR archive. This obviates the need to bundle a common JAR archive with every application.