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.
