HOME     PRODUCTS     DOCUMENTATION     EXAMPLES     NEWS     COMPANY     CONTACT 
NEW!  JPlates 3.0.2 is now available. Click here for more information.
Try out JPlates 3.0.2. Click here for more information about your free evaluation.
Why object-oriented template processing? Click here to learn more.
Read the JPlates FAQ. Click here for answers to frequently-asked questions.

JPlates™ - Dynamic Struts Reloader

JPlates 3.0.2 includes development-time support for dynamic reloading of classes and configuration files, without restarting your web server or servlet container.

The dynamic reloading behavior is also available just for Struts, and can be dowloaded for free.

Click here to review the JPlates license agreement and download the Struts reloader.

Links to sections below:
Configuration
How it works
Problems to watch out for

Configuration

To take advantage of this behavior, it is necessary to configure the web.xml file to specify this class as the Struts servlet class, and to configure the struts-config.xml file (or module config files) to specify the inner class DynamicRequestProcessor as the controller processor class.

For example, in your web.xml file: 

  <servlet>
    <servlet-name>
        action
    </servlet-name>
    <servlet-class>
        com.jplates.servlet.util.DynamicActionServlet
    </servlet-class>
    <init-param>
      <param-name>DYNAMIC_CLASS_UPDATES</param-name>
      <param-value>true</param-value>
    </init-param>
    ...
  </servlet>

To disable the dynamic reloading behavior for production deployment, simply change the init-param value to false.

In your struts-config.xml files (or module-config files): 

  ...
  <controller processorClass=
   "com.jplates.servlet.util.DynamicActionServlet$DynamicRequestProcessor">
     ...
  </controller>

How it works

Classes, properties files, etc. are reloaded from the WEB-INF/classes directory tree using a custom ClassLoader that takes over full responsibility for loading classes and resources from the WEB-INF/classes directory tree.

When a request is made in new HTTP session, a check is made to see if any files in the WEB-INF directory tree are newer than the current ClassLoader. If so, a new ClassLoader is constructed for the new session, and for other new sessions until newer changes are detected.

In addition to the new ClassClassloader, the DynamicActionServlet is reinitialized, causing Struts to reload all XML configuration files and to decache references to classes loaded by previous ClassLoaders.

Because the approach uses new ClassLoaders even for Action and ActionForm classes, it should not be enabled or used for production deployment (see problems section below).

Problems to watch out for

1. ClassLoader Collisions

Reloading classes in new ClassLoaders can result in a variety of hard-to-debug problems. There are several things that your application might do that will thwart the stragegy, including the following.

  • Initially loading classes from a jar file, and then try reloading them from the /WEB-INF/classes directory tree (that generally won't work!).
  • Storing instances of classes from your /WEB-INF/classes directory in the application-scope or in other global tables.
  • Storing instances of java.lang.Class or java.lang.ClassLoader in any of your data structures.
  • Saving instances of your classes in static variables, instance variables of your Actions, or anywhere other than in the session scope, request scope, or page scope.
  • Anything else that allows classes loaded by a new ClassLoader to encounter classes loaded by an older ClassLoader.
If this kind of problem does occur, the most likely observed failure is a ClassCastException involving another class (from another ClassLoader) with the same name as the expected class. If such an exception occurs only when you reload classes, the reloading in combination with unintentionally cached classes is the most likely cause.

This kind of problem can also occur in sessions that started before a ClassLoader change. The typical problem is that objects in the Session scope (such as the ActionForm) were loaded by a different ClassLoader than the code that needs to use them (such as Action classes). Consequently, the reloading functionality should only be used during development, and old sessions should be abandoned when class changes are made.

2. Hidden or Unintended Caching

The strategy for reloading classes is completely reliable, but unintended file and/or data caching can interfere with reloading of configuration data.

In other words, when changes are detected and a new ClassLoader is put in place, you will always observe the new classes. Under some circumstances (such as when proxy caching is being used), modified configuration information is not observed after the first change.

Most of the time this problem will be resolved properly on the second modification, so you can fix this problem by modifying the configuration file again and starting a second session.