We want to hear from you! Please send us your FEEDBACK.

Overview

In this article we'll look at Dynamic Reloading in the iPlanet[tm] Application Server v6.0/6.5 Enterprise Edition. We'll examine how to enable Dynamic Class Reloading for the different Java[tm] 2 Enterprise Edition (J2EE[tm]) components, the fundamentals of how Dynamic Reloading works and finally, at why you would use it and some of the things to look out for when you do.

Dynamic Class Reloading in iPlanet Application Server ("iAS") allows changes to specific J2EE application class files to be picked up by the Application Server without the Server having to restart. This can be extremely useful in a development environment where a developer would want to test changes made to Java[tm] Servlet/Enterprise JavaBean[tm] (EJB[tm) class files and JavaServer Pages[tm] (JSP[tm]) without the overhead of stopping and starting the Application server ("App server"). It could feasibly be used in a production environment where downtime of the application server needs to be kept to a minimum but where changes to application class files are frequent, although this isn't recommended.

How to Enable Dynamic Class Reloading

In iAS 6.0, Dynamic Class Reloading is enabled through changes to the iAS registry. In iAS 6.5 Enterprise Edition, things have been simplified through the addition of a Dynamic Class Reloading checkbox to the iAS Administration Tool (iASAT). In the iAS 6.0 registry, the key that needs to be changed is Software\iPlanet\Application Server\6.0\CCS0\SYSTEM_JAVA\Versioning. This key contains several values, although only the value of 'Disable' is relevant to the Dynamic Class Reloading of J2EE Components. The value of 'Disable' indicates whether Dynamic Reloading is disabled or not. A value of '0' means that Dynamic Class Reloading is not disabled. While a value of '1' indicates that Dynamic Class xexpovi star Reloading is disabled. The other valuesall begin with GX and are applicable only to AppLogic components which are now deprecated. In iAS6.5, iASAT includes a checkbox on the General tab that can be used to enable/disable Dynamic Class Reloading. This checkbox controls (and reflects) the value of 'Disable' in the registry key Software\iPlanet\Application Server\6.5\CCS0\SYSTEM_JAVA\Versioning.

As soon as you enable Dynamic Class Reloading, all Servlet class files, registered JSPs and EJB implementation classes will be dynamically reloaded. Unregistered JSPs (JSPs that have not been given a GUID) are always dynamically reloaded. Helper classes and EJB home and remote interfaces will not be dynamically reloaded.

How It Works

Each J2EE application (EAR file) deployed on the iPlanet Application Server will have its own classloader which we will call the Application classloader. While all standalone modules (EJB JAR files or Web Application WAR files) that are deployed on the App server will share a single classloader that is independent of the classloaders used for the J2EE applications. We will refer to this as the Module classloader. Note that there can be many Application classloaders but only one Module classloader. When enabled, Dynamic Class Reloading will be applied to all Servlet classes, JSP compiled classes and EJB implementation classes that are deployed on the App server. To make Dynamic Class Reloading work, each of these classes will be loaded by its own classloader. For each Servlet and JSP this will be an instance of what we will refer to as a Web classloader, and for each EJB (implementation class) this will be an instance of what we will refer to as an EJB classloader. Each of these new classloaders will have as a parent either the Application classloader for the application that it is part of or, if it is part of a standalone module, the Module classloader. When an update is made to one of these classes the Application Server picks up on the changes. It then creates a new instance of the appropriate classloader and uses it to load the updated class. For a Servlet or JSP it will then create a new instance of this class to service any future requests while for an EJB it will recreate all of the bean instances in the pool.

The classloader hierarchy with Dynamic Class Reloading enabled is as follows:

                                       Bootstrap Classloader


                                       Extension Classloader


                                         System Classloader


                           Module                             Application
                        Classloader                           Classloader


                   Web            Ejb                     Web             Ejb
               Classloader    Classloader              Classloader   Classloader

Note that as described earlier there are likely to be multiple Application classloaders as well as multiple Web and EJB classloaders.

Why We Would Use Dynamic Class Reloading

There really is only one reason to use Dynamic Class Reloading and that is to have the App server pick up changes to JSPs, Servlet classes and EJB Implementation classes without having to restart. This can considerably reduce development time as it becomes very easy to test small incremental changes to an application without having to suffer the overhead of stopping and starting the App server. It is also extremely useful in situations where many developers are testing different applications on the same App server instance. In a situation like this, restarting the App server could impact the work of many developers. Dynamic Class Reloading does have a considerable performance overhead and therefore, it is not recommended for use in a production environment. This overhead is incurred not just when a class is being reloaded but is continuous due to the need to constantly monitor classes for changes. If performance is a key non-functional requirement of a production system then Dynamic Class Reloading should be disabled.

Things to Watch Out For

The use of Dynamic Class Reloading can introduce problems when classes that are being dynamically reloaded make calls to non-public methods of helper classes that are in the same package. Such calls are likely to cause a java.lang.IllegalAccesserror to be thrown. This is because a class that is dynamically reloaded is loaded by a different classloader than the one used to load the helper classes. Classes that appear to be in the same package are effectively in different packages when loaded by different classloaders. If class com.myapp.MyServlet is loaded by one classloader and an instance of it tries to call a non-public method of an instance of class com.myapp.Helper loaded by a different classloader, the call will fail because the two classes are in different packages.

When an application class is Dynamically Reloaded a new instance of that class is created and loaded. Therefore, any static (or class) variables will be reinitialized. This means that static variables are not really suitable for storing application state, particularly if that state reflects the number of times the application has been invoked. For Servlets and JSPs, an alternative is to store application state within the ServletContext object (the ServletContext is represented by the implicit application object for JSPs).

Another thing to be aware of is that Dynamic Class Reloading affects the order in which classes are loaded. With Dynamic Class Reloading disabled, all of the classes in all of the standalone Web Modules (Web Modules not deployed as part of a J2EE application) will be loaded by the same classloader. If there are two classes with the same name (possibly two different versions of the same class) in different modules then the last of these classes that is loaded will be the one that is used whenever an instance of that class is created. With Dynamic Class Reloading enabled the Servlet classes will be loaded by a separate classloader. If there is more than one version of the same Servlet in the deployed Web Modules then the version that has the latest timestamp will be loaded by this classloader. It is possible to get into a situation where you are constantly making changes to a Servlet class and testing these changes, but when you then disable Dynamic Class Reloading and restart the App server, you find that the version of the Servlet class that is used is not the version that you have been working on!

DOC ID #1193