If you've had the pleasure of working with BEA WebLogic Server for several years, you may know that RMI/T3 calls between different releases of the server used to be disallowed ­ to be buzzword -compliant, the releases were not "wire compatible."

For example, you couldn't call an EJB deployed on WebLogic Server 4.5.1 from a WebLogic Server 5.1 application. This often meant that groups of applications had to be migrated together to new versions of WebLogic Server.

The lack of wire compatibility became more of a problem as users began to put increasingly sophisticated WebLogic Server configurations into production. Engineering stepped up to the mark and WebLogic Server 6.1 became the RMI/T3 "interoperability baseline" ­ interoperability between 6.1 and a number of future releases is designed into the product. New features such as Web services and enhanced RMI/IIOP also provide creative alternatives.

Not everyone has the luxury of green field sites using the latest WebLogic Server releases. In this article, I describe a scheme for sending JMS messages to both a WebLogic Server 5.1 application and a WebLogic Server 6.1 application from a single client. The approach I take is to use a special class loader that allows both versions of the RMI stack to be loaded into a single Java Virtual Machine (JVM).

A warning: you might need your propeller-head hats for some of this. I hope you come out the other side with an enhanced understanding of how class loaders work and how to use them to your advantage. The technique is not limited to addressing WebLogic Server interoperability problems; it can be applied wherever you want to load more than one version of a particular code base in a single JVM.

The full source code for this article can be found on the WLDJ Web site at www.sys-con.com/weblogic/sourcec.cfm.

So What's The Problem?
For a client to engage in RMI communication with a particular version of WebLogic Server, it must have the appropriate classes available. Usually, this means adding the WebLogic classes directory (for 5.1) or weblogic.jar (for 6.1) to the client's system classpath. The client uses these classes to communicate with the server and RMI stubs for application types are then retrieved from the server at runtime. Unfortunately, RMI classes and stubs from WebLogic Server 5.1 are not compatible with those from WebLogic Server 6.1; they can't be loaded together.

Java uses class loaders to control how classes are located and loaded into the virtual machine. Each class used by a program belongs to a class loader and, by default, a method uses its caller's class loader to load other classes. Class loaders are arranged in a hierarchy, with the Java boot, extension, and system class loaders at the top of the hierarchy. By convention, class loaders defer to their parents, meaning that when asked to load a particular class they give their parent class loader the option to load it instead. This is usually sensible; it minimizes the number of instances of a class that are loaded and allows parts of an application that use different class loaders to communicate through a set of common classes loaded by a parent class loader.

It's quite possible for a class with the same name to be loaded independently in two different class loaders and in this case the two instances are treated as distinct. By creating appropriate class loaders, you can partition parts of your application into separate "sandboxes" and ensure that classes one application component loads do not affect other components. This is what WebLogic Server 6.1 does to ensure that Web applications and enterprise applications are kept separate from one another. Refer to http://edocs.bea.com/wls/docs61/ programming/packaging.html#1048725 for details. The WebLogic Server class loader also supports dynamic loading and unloading (hot deployment) of Web applications and enterprise applications. An interesting article on writing dynamic class loaders can be found at www.javageeks.com/Papers/ClassForName/index.html.

By now, I think you can see where this is going. We should be able to load the two versions of the WebLogic Server RMI classes in separate class loaders. Our client needs to access both JNDI and JMS services from the two servers. The services are implemented differently in the two server versions, and we'll need to load two sets of the classes and stubs. We can't load everything in isolation though; the JNDI and JMS interfaces must be loaded in a single class loader so we can compose a useful program that calls both servers. Figure 1 shows the class loader hierarchy we will use.

An alternative strategy would be to load one version of the RMI classes and stubs in the same class loader as the controlling code (the main method in our example). This would be the case if you were using the technique to call out from a servlet running in one version of WebLogic Server to an Enterprise JavaBean running in another. I chose to use a distinct class loader for each version of the RMI classes because the symmetry makes the code simpler to understand. However, the class loader implementation I provide allows you to take either approach.

The Isolating Class Loader
If you've been paying attention, you might be wondering about the previous paragraph. How would a WebLogic Server 6.1 class loader work if the WebLogic Server 5.1 RMI classes were loaded in the system classpath? When asked to load a particular class, wouldn't the WebLogic Server 6.1 class loader first call the system class loader (its parent), which would erroneously load a WebLogic Server 5.1 version of the class?

This would certainly be the case for a conventional class loader, which would always defer to its parent first, but I've created an unconventional class loader, IsolatingClassloader. Each IsolatingClassloader is constructed with a list of packages and classes that it should load, and a class path that specifies where to load them from. This method is called to load a class and is shown in Listing 1.

IsolatingClassLoader first determines whether the class name is one that should be loaded in isolation, and if so, attempts to discover and load the class and make it available to the JVM. The class loader asks its parent to load the class only if the class is one that shouldn't be isolated or an implementation cannot be found.

Putting It To Work, The JMS Client
The supplied example client has four command-line parameters, the classpath and JNDI provider URL for each of the servers. Listing 2 is an example of the client running against the two servers. Note that I added the WebLogic Server 5.1 weblogicaux.jar file to the system classpath. This contains the JNDI and JMS interface classes.

To call a particular version of the server, we first construct an instance of IsolatingClassLoader that will isolate the WebLogic implementation classes (package names beginning with weblogic and COM.rsa) and set an appropriate classpath. We can then use the code in Listing 3 to call either version of the server. All that changes from server to server is the isolating class loader instance and the JNDI provider URL.

I guess you're wondering what those setContextClassLoader calls are doing? These calls set a "context class loader," which is associated with the current thread. The Java JNDI and RMI interface classes use the context class loader to determine how to load the implementation classes.

I encourage you to download the source code to see just how elegant the class loader solution is. With the exception of the IsolatingClassLoader setup and the calls to setContextClassLoader, the application code uses the standard J2EE API's.

Bridging Interface Differences
By now you can appreciate the appropriate emerging pattern when using IsolatingClassLoader to call several different versions of an implementation. Interface code is loaded in a common class loader; implementation code that needs to be isolated is loaded in its own IsolatingClassLoader. But what if the interfaces themselves vary?

In fact, this is the case for our JMS example. WebLogic Server 5.1 uses JMS 1.0.1, whereas WebLogic Server 6.1 uses JMS 1.0.2b. There are minor API differences in the handling of TopicConnections between the two versions of the JMS specification. Even if you don't create a TopicConnection, you'll run into this problem when you attempt to employ the IsolatingClassLoader technique to make WebLogic Server 5.1 JMS calls from a WebLogic Server 6.1 application. WebLogic Server 5.1 RMI performs strict type- checking that uses the stub interface and throws a ClassCastException if the local interface type does not exactly match the remote interface type. The mirror image of the scheme, with a WebLogic Server 6.1 IsolatingClassLoader embedded in a WebLogic Server 5.1 server, works fine because WebLogic Server 6.1 RMI uses dynamic proxies and is more relaxed about the API differences.

All is not lost. I've successfully extended the IsolatingClassLoader pattern to address this problem. I don't have room to cover the full solution here, but I will briefly describe it. I used a proxy object, residing in the common WebLogic Server 6.1 class loader, which maps JMS 1.0.2b calls to a neutral interface (a subset of the JMS 1.0.1 and 1.0.2b interfaces). A second proxy object, which is loaded by the WebLogic Server 5.1 IsolatingClassLoader, maps calls from the neutral interface to the JMS 1.0.1 interface. I managed to hide this implementation from application code by binding the entry points of the interfaces (connection factories) into the WebLogic Server 6.1 JNDI tree. Look out for this trick in the JMS Bridge that comes with the next release of WebLogic Server.

That's all for this month. I hope I've given you a different perspective on Java class loaders, and that you'll find it useful when wiring WebLogic Server applications together. Till the next time…