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
occurring.
> 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
>
>
Craig
