The functionality described in this article is available at the moment only in JavaRebel nightly builds.

One of the main problems that comes up with JavaRebel is compatibility with a multitude of platforms for application development. Just recently we implemented support for Orion, Resin and Eclipse, with many more awaiting our attention. The main reason for this is that to reload the classes we first need to determine where they are located on the file system. The only place to get such knowledge is the classloader, which does the actual resolving. And different classloaders may do that differently — therefore the trouble in supporting them all.

However in some cases integration should be easier. Specially, many custom classloaders will just inherit from URLClassLoader and delegate the actual loading to it. Other classloaders will override some of the logics, but provide the correct location of classes on the file system via getResource() URLs with “file://” protocol. We have implemented generic support for both these cases and will review the necessary steps here.

The following steps will currently only work with Java 5 installation mode (”-javaagent:javarebel.jar -noverify”).

Step 1: URLClassLoader support

So what do you need to do to enable generic support for URLClassLoaders? Absolutely nothing! If this is the case your application (or server, or platform) should just start working and reloading those classes. We have tested this with Tomcat and Jetty, which both feature URLClassLoader derivatives and it works like a charm.

Step 2: Custom class loader support

So what if it doesn’t “just start working”? This means that either your classloader isn’t a derivative of URLClassLoader or it does inherit some functionality, but overrides the critical one. For this case we have another trick up our sleeves.

First you need to determine the class name of the classloader in question. The easiest way to do it is put the following line in any class that will be loaded by that classloader (e.g. in a web application case it could be a servlet class):

System.out.println(getClass().getClassLoader().getClass().getName());

This will print the name of the classloader class right out to the console. Let’s assume the name was “com.acme.CustomClassLoader”. In that case all we need to do is pass it to the JavaRebel agent like this:

-noverify -javaagent:javarebel.jar=com.acme.CustomClassLoader

Sometimes there could be several different custom classloaders and in such a case a comma-separated syntax should be used:

-noverify -javaagent:javarebel.jar=com.acme.CustomClassLoader1,com.acme.CustomClassLoader2,...

This should get most of the custom classloaders to work.

Step 3: Contact ZeroTurnaround

The features described in this article will work in most cases. However sometimes class loaders are trickier and we need to do some work to support them. As an example, both Orion and Resin were integrated using the generic methods, whereas Eclipse was not. The problem with Eclipse was that it features OSGi classloaders, which have an internal “bundle://” resource protocol and some work needs to be done to determine the actual files behind the resources. So if you find that no matter what you do you can’t get the classes to reload just contact ZeroTurnaround via support@zeroturnaround.com and we will be glad to help!

This entry was posted on Tuesday, November 13th, 2007 at 4:58 pm and is filed under articles, blog, news. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.