"Scott M. Stirling" wrote:
> On 05 Jan 2001 16:35:09 -0800, Hans Bergsten wrote:
> > "Scott M. Stirling" wrote:
> > > 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that
> > > will never get dumped unless the server is shutdown? Just a matter of
> > > elegance, I suppose.
>
> [Hans Bergsten]
>
> > Yes, it does. But AFAIK there's no way you can just unload a class
> > from the JVM; you would have to drop the class loader for the
> > context and reload all classes that are still valid. That doesn't
> > seem like the right thing to do in this situation IMHO.
>
> It depends how class loading in Tomcat works. I'm familiar with JRun
> 3.0, which works like this (I'm not giving away any family secrets, this
> stuff is documented in various places in Allaire docs):
>
I'm not giving away family secrets either ... it's all out there in the source
code :-)
>
> - servlets & JavaBeans (even those called by JSPs) - loaded by a
> classloader with web-app scope. If a single servlet changes, the whole
> web-app's classloader is dumped so the servlet can be dynamically
> reloaded. No need to actively reload the other classes that got dumped
> with the classloader. They'll be reloaded as needed when requests come
> in for them.
>
Tomcat does pretty much the same thing. How reload checking is implemented
depends on which version you're talking about (assuming you've marked your app
for reload checking):
* Tomcat 3.2 - on each request, it checks the servlet you asked
for, and reloads the entire webapp if it's been updated. This is
why it sometimes misses changes to bean classes.
* Tomcat 4.0 - a background thread checks for updated classes
(default interval is 15 seconds), and reloads the wbapp if any have
been changed.
In neither case are classes loaded from the shared library directory
($CATALINA_HOME/lib), or any higher-level classloader, checked for updates. The
reason is that we cannot throw those classes away anyway, without throwing away
*all* of the current webapps.
When Tomcat reloads a webapp, it also attempts to save all the current sessions
(and their attributes, if they are Serializable) and reloads them again. This
is necessary because the bean classes were loaded by the "old" webapp class
loader, so attempting to reference them from a bean class loaded by the "new"
webapp class loader (after the reload has been completed) would cause a
ClassCastException (even though the class names are the same).
>
> - JSPs are each loaded in their own classloader. So if a JSP is changed
> and reloaded, the old classloader is dumped and a new one created.
> JavaBeans are delegated to the web-app classloader, for whatever reason.
>
Jasper does the same, and makes the webapp classloader the parent of the JSP
page classloader so that a page can reference beans and other classes known only
to the webapp. For Tomcat 3.2, which has to run under JDK 1.1, the Java2
delegation model is essentially faked by custom ClassLoader implementations to
reproduce the "parent" relationship.
Jasper also plays some wierd games with the classnames of the generated pages --
this is an area I think needs to be cleaned up in the 4.1 time frame, as Jasper
is migrated to using Java2 facilities directly (because servlet 2.3 and JSP 1.2
require a Java2 platform).
>
> All this may change in future versions, when JRun reloads tag handlers
> dynamically. I have no idea how Tomcat handles these classloader
> issues, but it would be interesting to hear about if anyone can distill
> it briefly.
>
Right now, Tomcat will treat changes to tag library classes just like it does to
bean or servlet classes, and chucks the whole webapp. It might be worth looking
at whether you can get away with doing less than that for tags.
>
>
> --
> Scott Stirling
> West Newton, MA
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
