dynamic reloading of struts-config and classes for Struts 1.1 and JPlates 3.0 - 99%

[Dan Jacobs <dj...@modelobjects.com>]

Hi all,

I have implemented a scheme for dynamically reloading classes and struts 
configuration files for JPlates 3.0.1 and Struts 1.1, and welcome anyone 
interested to try it out.  Everything you need is in the JPlates trial 
download at http://www.jplates.com, and the config setup is described in 
the examples on the site and in the Java-doc.  The scheme is designed to 
work even if you don't use JPlates.

As indicated in the subject line, this is only a 99% solution so far, 
even if you don't do anything in your code to thwart the strategy 
(things to avoid are enumerated in the Java-doc).  Here's how it works.

1.  There's a subclass of ActionServlet that uses a class-loader-manager 
to watch for changes in the WEB-INF directory tree of the 
web-application.  It only looks for changes when it responds to the 
first request of a new session (that's both for performance reasons and 
to avoid class-loader collisions within a session).  You can override 
the out-of-date checking behavior by providing your own FileFilter in a 
subclass.

2.  The class-loader takes over loading classes and other resources from 
the WEB-INF/classes directory.  It does not do anything with jar files 
in the WEB-INF/lib directory, since in most cases those files are kept 
open for direct file access.

3.  When changes are detected and a new class-loader is constructed, the 
ActionServlet subclass re-initializes itself, re-loading the 
configuration XML files, etc.  This isn't a very straightforward thing 
to do, and there's probably code in there that's completely Struts-1.1 
specific.

This scheme has been fairly well tested, but only under Tomcat 4.x and 
5.0, and not in a production multi-client environment.

PLEASE NOTE:
I have noticed one peculiar problem that I haven't been able to track 
down.  If you modify classes in the WEB-INF/classes directory and start 
a new session, the changes take effect immediately.  But if you modify 
your struts-config.xml file and start a new session, those changes are 
not seen the first time.  If you touch the file again and start another 
session, the changes are then seen.  In fact, every even numbered change 
to the struts-config file works properly.  If anyone has any insights 
about that, I'd be very interested.  I've seen similar behavior using 
custom class-loaders with Tomcat, but don't know what causes it.

I expected that some J2EE containers will put up a fuss about this 
ActionServlet subclass creating new class-loaders.  You'll have to grant 
permissions in that case.  I also anticipate class-loader collisions 
with multiple concurrent sessions, and I'm working on a design to 
address that problem.

Please try this out.  I've already found it to be a great time-saver, 
despite its current limitations, and I'd like to make it even more 
useful based on your feedback.

All the best,
Dan Jacobs
President, JPlates Inc.