> craigmcc 01/06/22 14:57:08
>
> Log:
> Add some unit tests for bean references from a servlet (Session01 or
> Session03) to beans in the following locations:
> * SessionBean is in the same /WEB-INF/lib/tester.jar JAR file as the
> servlet classes are
> * UnsharedSessionBean is unpacked under /WEB-INF/classes in the
> tester web app, but should be loaded by the same webapp class loader
> that loads the servlet.
> * SharedSessionBean is in a JAR file under $CATALINA_HOME/lib, so it
> should be loaded by the parent classloader
>
> There definitely appears to be a problem with class loading, and trying
> this stuff fails under either WebappClassLoader and StandardClassLoader.
> Right now, I've commented things in the build.xml file out so that all
the
> classes get built into tester.jar, and running the "HttpSession" target
> all succeeds.
>
> If you uncomment the following sets of lines in build.xml, though:
> * 75-76 to copy UnsharedSessionBean to /WEB-INF/classes
> * 95-96 to exclude SharedSessionBean and UnsharedSessionBean
> from tester.jar
> * 151-156 to create and deploy SharedSessionBean into the
> $CATALINA_HOME/lib directory
>
> then you will get NoClassDefFound exceptions when trying to execute
either
> Session01 or Session03.
>
> Conclusion: class loading fails when a class within a JAR file under
> /WEB-INF/lib references a class in /WEB-INF/classes, or in a shared JAR
> file in the parent class loader.
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.
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
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
