tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unshared UnsharedSessionBean.java
Date Fri, 22 Jun 2001 23:49:26 GMT
> 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


Mime
View raw message