tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unshared
Date Fri, 22 Jun 2001 23:57:00 GMT

On Fri, 22 Jun 2001, Remy Maucherat wrote:

> I don't think that test case is valid.
> Both of the following explanations are theories. I could be wrong. Comments
> by CL gurus are welcome.
> Case A (Craig's test) :
> Basically, what happens here is :
> - The Webapp CL which manages the tester webapp loads Session01
> - It then notices it needs to be linked with other classes (SessionBean,
> SSB, and USB)
> - It loads USB, no problem
> - It asks the parent CL to load SSB, because it can't find it
> - Parent loads SSB, checks linking
> - It notices it needs to load SB
> - It can't find SB (since it's in his child CL repository)
> I don't see how we can have that work. It's a case where classes from the
> shared loader depend on classes from the webapp loader.

Yep, you are right on SSB.  I'll change it to not be a subclass.

However, that doesn't explain why it fails on USB -- that's loaded by the
same classloader as Session01, so it should still work.  The only
difference is that USB is in /WEB-INF/classes instead of
/WEB-INF/lib/tester.jar like SessionBean is.  You can uncomment just the
parts of build.xml that do UnsharedSessionBean, and it will still fail.

NOTE:  Even though the log file says it was copying the classes
repository, only the JAR files were copied.  Is it supposed to copy
/WEB-INF/classes/* as well?  If so, that's probably why the error is

> Case B (Jon's reloading) :
> - Class A which depends on class B (which is also loaded by CL 1 -
> everything would be ok if it was loaded by the parent CL) gets loaded
> (perhaps along with class B) by CL 1
> - Touch class A
> - Reload
> - CL 1 gets destroyed, and CL 2 is created, and contains the same
> repositories as CL 1
> - all the classes loaded by CL 1 are still there
> - Later, reload new class A
> - New class A needs class B, which CL 2 doesn't know
> - CL 2 loads another class B
> - The other objects instance of the old class B are unaffected, which leads
> to an error at some point

What other old instances of class B are still around at that
point?  Reloading should have made them all go away.

> To solve this, I would try doing a ctx.stop + ctx.start (instead of
> ctx.reload) whenever class reloading is needed. I think the current
> reloading will only be able to reload reliably things like the HelloWorld
> servlet (ie, classes which are fully independent from other classes from the
> webapp).
> Remy


View raw message