http://www.dev2dev.co.kr/pub/a/2002/10/musser.jsp
引用:
Making the Most of WebLogic Classloaders
by John Musser
2002/10/29
As a Java developer, have you ever found yourself running into what might be politely called 'issues' related to the CLASSPATH and class loading? If you haven't, you're one of the few. This is one of the most notorious sources of developer aggravation in Java development. Now J2EE has added a new set of wrinkles to this phenomenon.
This article dispels some of the mystery of what's going on behind the classloader curtain and provides insights into how you can use this knowledge to your advantage when designing, packaging, and deploying your WebLogic Server applications. Important items we'll cover include a refresher on class-loading fundamentals you need to be aware of; how WebLogic's own custom classloaders build on these basics; the often misunderstood relationship between classloader hierarchies and EARs, EJBs, and WARs; techniques for packaging and deploying utility classes; and a simple but handy tool for diagnosing how classes are loaded within your applications.
Quick Classloader Review
Let's begin with a short review of how classloaders work: Classes are loaded when new bytecode is executed for the first time, either via a new class instance as in "MyClass x = new MyClass();" or by a first reference made to a static class, "MyStatic.staticMethod();". When this occurs, the JVM relies on classloaders - either the standard Java classloaders that ship with the runtime or custom classloaders - to load the bytecode in memory (all classloaders are subclasses of java.lang.ClassLoader). While there's a standard format for how the class is loaded in memory, where a classloader loads the bytecode from, be it from the file system (your typical .class files), an archive (JARs), a network socket (think applets and RMI), or even generated on the fly, is left to each classloader.
Nonetheless, there are certain rules all classloaders follow, many of which can ultimately impact your WebLogic applications. In particular, they:
- Are hierarchical: As of JDK 1.2 all classloaders exist in parent-child relationships. Each classloader, other than the initial loader, has a parent classloader. The root parent classloader, built into the virtual machine, is called the "bootstrap" (or "primordial") classloader.
- Can have siblings: Given that any classloader may have multiple child classloaders, it's possible for these children to have sibling classloaders at their same level in the hierarchy.
- Delegate load requests: Before attempting to load classes themselves, children delegate all load requests to their parent. And each parent will delegate to its parent until reaching the root of the hierarchy. Only if any parent does not first resolve a request does a child attempt to load the requested class.
- Have visibility constraints: Child classloaders, and the classes loaded by these loaders, have access to (or can "see") classes loaded by their parents, but parents cannot access classes loaded by their children nor can children see classes loaded by sibling classloaders (as with delegation, this only goes up the hierarchy, not down).
- Cannot unload classes: Classes cannot be unloaded directly by their classloader, but classloaders themselves can be unloaded. This effectively unloads any classes loaded by that classloader. More about this soon.
Classloaders in a WebLogic Application
In order to support the J2EE standard and useful features such as hot deployment, WebLogic Server defines and initializes a number of its own custom classloaders. These classloaders work under the covers within the application server to manage loading and unloading your classes, EARs, EJBs, and WARs (and if you're interested in writing your own specialized classloader, you might want to take a look at Philip Aston's excellent article on this in April's WLDJ [Vol. 1, issue 4]).
Always keep in mind that class loading and deployment are inseparable. When you deploy your modules to WebLogic, each is typically loaded in its own dynamic classloader. If you're deploying a single EJB JAR file, it will get its own classloader. When you deploy a single WAR file, it gets one too. And when deploying an EAR file, WebLogic will create, depending on what's in your EAR file, an entire hierarchy of classloaders.
How does this work? What rules does WebLogic follow? The principal concept is that of application deployment units such as an EAR, an EJB, or a WAR. When any of these are deployed separately they are loaded in separate sibling classloaders. If EJBs and WARs are grouped into an EAR, they get a hierarchy of classloaders: at the top is the application classloader, which loads the EJBs and JARs referenced in its manifest file's classpath (more on this later), and then classloaders for each WAR file.
Figure 1 illustrates a sample WebLogic Server deployment. Each shadowed box in the WebLogic section represents an independent classloader instance. At the top level we have two EARs, one EJB JAR, and one WAR. Each of these is loaded by a sibling classloader. Within the first EAR are three EJB JARs (each with potentially multiple EJBs) and manifest-referenced utility files that share a single classloader and two Web applications that each get another classloader. Because of the established classloader hierarchy, the JSPs, servlets, and utility classes in both WARs can directly use any of those EJBs. In the second EAR, a simpler hierarchy allows the same interactions as the first, but these components are isolated from those in the first EAR.
In this arrangement, if either of the independently deployed modules, the EJB or the WAR, needs to access the other, this must be done via remote interfaces. This means that the EJB home and remote interfaces must be packaged into the calling modules and all communication may require more overhead than if they were packaged together (in which case WebLogic can perform various call optimizations such as using call-by-reference as it does for new EJB 2.0 local interfaces).
Table 1 lists the primary classloaders in a typical WebLogic EAR application. These are listed in order of creation from the primordial bootstrap classloader through various child classloaders down to the Web classloader. A couple of notes here: each of these classloaders may or may not be a distinct ClassLoader subtype or may be multiple instances of the same class configured differently. WebLogic may internally use additional classloaders (the details of which don't matter to us here); the native JVM classloaders are not set up to be reloadable but WebLogic's are (thus the familiar problem of having to reboot the application server if classes loaded by the non-reloadable classloaders have changed).
What This Means
The consequences of this classloading scheme include:
- Isolation: The positive, deliberate side effect of the lack of sibling classloader visibility is isolation - classes loaded by different classloaders at the same level do not, and cannot, directly access one another without explicitly including the other's remote interfaces. You can see an advantage of this sand boxing by looking at how WebLogic handles EAR files: each is run in its own classloader instance and can be deployed and redeployed independently. This means that when you and I both deploy our separate applications to Server A, we can do so in parallel without worrying about a host of issues that might occur if we shared the same classloader. As the old adage goes, fences make for good neighbors.
- Visibility: A key benefit of the hierarchical approach to classloader visibility is that JSPs, servlets, and other Web application components have direct access to all EJBs within the larger application. This both simplifies deployment and gives the application server more opportunities to optimize the performance of calls between components (covered in more detail below).
- Namespaces: Class instances within the JVM are identified by the combination of the full classname and the classloader that loaded it. This namespace identification can come into play in your WebLogic applications. For example, think about how common it is for a Web application to start from a JSP or servlet with a standard name like index.jsp. That's fine. But what happens when you have two Web apps (two WAR files) within the same EAR and both of those apps have that innocuously named JSP or servlet? Without the benefit of classloader isolation, after the compiler finishes turning those source files into compiled servlets, a namespace or class-loading issue occurs because they both resolve to the same name, resulting in only one being loaded. Regardless of what happens in that scenario, it won't happen in WebLogic because each WAR is loaded in its own classloader and even if the JSPs or servlets have the same name, each exists independently as far as the classloaders are concerned.
- Performance: Keep in mind that class loading, or more generally, packaging, impacts performance. Components deployed together in an EAR allow the WebLogic Server to optimize performance by reducing RMI call overhead as well as allowing you to use the new EJB 2.0 local interfaces. And it's through the default class-loading behavior (whereby loading is first deferred to parents as opposed to having each classloader load its own copy of the same class) that overall memory consumption is reduced.
- Singletons: If you use the singleton design pattern in your application you need to be aware that classloaders matter because singletons (at least the run-of-the-mill, GoF design pattern variety such as those accessed with a getInstance-type method) exist not just within a single JVM but within a single classloader. Thus, if the singleton is loaded at the EAR level (such as from a utility library included at that level and not at the system-wide classpath level) by EAR 1 and EAR 2, then each application will get a different copy of that singleton. And there are of course other caveats to be aware of with singletons: clustering can throw a monkey wrench into the works, and in a world of distributed objects other patterns may be necessary, such as using JNDI to manage a singleton EJB (see some active discussions on this topic at www.theserverside.com).
- Deployment: Regardless of how you deploy your application module - by using the console, by WebLogic's automatic hot deployment mode (quite useful during development), or through command-line utilities - the server will create a new classloader instance for loading this application. If you choose to deploy EJBs and WARs separately and you want your Web application to use those EJBs, you'll need to include the EJB home and remote interfaces in your WAR file. These are loaded by sibling classloaders and you'll need to make remote calls across them. Similarly, if you want to reference EJBs across EAR files you'll need to package the home and remote interfaces from the one EAR into the other (or you could try the approach of generating client JARs for your EJBs by using the ejb-client-jar tag in ejb-jar.xml and add references to those JARs in the manifest classpath - see below for more about the manifest).
Handling Utility Classes
Nearly every application, large or small, needs utility classes, either your own or from one or more third parties. Given what we've seen in looking at classloaders and packaging, where can and should these go? Table 2 outlines some of the choices you have as well as their attendant pros and cons.
To elaborate a bit on the last item in Table 2: because they are JAR files, all J2EE modules have a MANIFEST.MF file in their META-INF folder. The J2EE specification allows classes in one JAR - such as an EJB or WAR archive - to access other JARs by explicitly adding their names to a special "Class-Path:" entry in the manifest file (this is built upon the "extensions mechanism" introduced in JDK 1.2). By using this entry you can tailor EAR class-loading behavior and can modularly deal with many of the classpath issues mentioned earlier.
In order to make this work, first create a text file specifying a list of JAR filenames as relative URLs separated by spaces and then include this file when building your deployment. Here's what a typical entry might look like:
<o:p> </o:p> Manifest-Version: 1.0 Class-Path: myparser.jar vendorlib.jar |
|
<o:p> </o:p> jar cmd mymanifest.txt myejb.jar com META-INF |
As an example, say you have a utility class, MyHandler, which for some reason (deliberate or accidental) appears more than once in your environment; it could be that the version loaded at runtime may not be the one you expect. If in this scenario your servlet (in a WAR file) instantiates MyHandler and the only physical location of MyHandler.class is under the WEB-INF/classes directory of that WAR, then this will be the one that gets loaded. But, if you have another version of MyHandler.class somewhere on the system classpath, it will be this one that gets loaded, regardless of the fact that there's one right there in the same archive as your program. |
<o:p> </o:p>