> 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.
Really ?
On my PC, if I copy the tester-shared.jar to /WEB-INF/lib, all the session
tests pass.
> 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.
No, it won't copy the classes.
> > 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.
I'm not too sure about that yet ...
Jon's case is quite complex, and is definitely not the same thing as your
test case.
Remy
