[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-general
Subject:    Re: Reload of Tomcat required when changes made to servlets?
From:       "Craig R. McClanahan" <cmcclanahan () mytownnet ! com>
Date:       1999-12-31 16:22:06
[Download RAW message or body]

Jim Rudnicki wrote:

> > Subject: Re: Reload of Tomcat required when changes made to servlets?
>
> > > That being said, I'm sure this will be a highly requested feature, and
> will
> > > therefore be near the top of the priority list.
> >
> > Probably in Tomcat 4.0?
> >
>
> I can agree that stopping and starting the server is a bit tedious during
> development, but I don't know if it is really better to be constantly
> checking timestamps during normal builds.  After all why constantly check
> "has it changed yet...no...has it changed yet...no...has it changed
> yet...no..."
>

The interesting part of implementing reloading is not really the administrative
issue of how do I request it, but rather it's the "what do I do now that it is
time to reload".  What you're saying you want to do is replace an existing
class (previously loaded) with a new one.  At first blush, the Java language
appears to provide no such mechanism.

The way most servlet engines (including Apache JServ) implement this is that
they provide a custom ClassLoader for all the classes that are subject to
reloading.  When you instantiate an instance of a new class for the first time,
the class itself (which is also an object) gets loaded by a class loader, and
then is used to load the remaining classes.  At reload time, what you do, in
essence, is throw away your reference to the class loader (which recursively
throws away all references to all classes loaded by that class loader, and all
objects of those classes).  Then, you create a new class loader and start
again.

Along the way, you are required (by the 2.2 spec) to avoid class cast
exceptions for the servlets you are loading (class "com.mycompany.Foo" loaded
by one class loader is different from class "com.mycompany.Foo" loaded by a
different class loader).  In essence, that boils down to loading all the
classes required for a particular web application from the same class loader.

>
> So I propose this: a development version of Tomcat.  If embedding is as
> simple as SimpleStartup.java suggests, then this wrapper's function could be
> expanded just a little to support a remote restart ability.  The restart
> would really be a delete and new.  And of course a tiny servlet would
> instruct the wrapper to restart.  The result http remote restart.
>

It's probably just as easy to provide a configuration switch (for Tomcat you'd
set it in the "server.xml" file) for whether to monitor classes for changes or
not.  That way, you don't need to maintain two versions of Tomcat itself.

Even if you do not leave auto-reloading turned off, the idea of being able to
manually request a reload is a really good idea.  In a long running server that
is supporting multiple web applications, you don't want to shut them all down
simply because you installed a new revision of one of the apps.  You could
signal the manual restart request by extending the existing admin interface, or
by providing a built-in servlet, but don't forget about some sort of security
to avoid "denial of service" attacks by continually asking the application to
reload itself.

>
> I wonder if the resulting server would still operate as a servlet engine for
> Apache. hmmm.  Tommorrow is a day off and the bunker doors are getting
> sealed at sunrise.  I may give this a whirl.
>

There's no reason that reloading should affect whether or not you can be
connected to Apache.  After all, Apache JServ has been doing this for years.
In fact, the custom class loader implementation in the Apache JServ code base
(org.apache.java.lang.AdaptiveClassLoader, at <http://java.apache.org>) would
give you a tremendous head start.  It should be useable (in Tomcat) pretty much
as is, and already supports the "automatic reload switch" capability described
earlier.

If you're really going to go after this, you might want to address any future
comments and questions to the TOMCAT-DEV mailing list as well.


>
> Jim
>

Hope everyone has a Happy Y2K Day!

Craig McClanahan

[prev in list] [next in list] [prev in thread] [next in thread]