DO NOT REPLY [Bug 12098] New: - Session manager and context class loader

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12098>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12098

Session manager and context class loader 

           Summary: Session manager and context class loader
           Product: Tomcat 4
           Version: 4.1.9
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: peter.brant@courts.state.wi.us


I'm using Filip Hanik's session clustering which uses JavaGroups.  I also use 
JavaGroups within my application.  So the structure looks like this:

[1] /server/lib/tomcat-javagroups.jar (Filip's replacement session manager)
[2] /server/lib/javagroups-all.jar (main JavaGroups library)
[3] /webapps/myapp/WEB-INF/lib/javagroups-all.jar

With Tomcat 4.0.3, this works great.

With 4.1.9, I get a ClassCastException when the session manager starts and 
tries to dynamically instantiate its protocol classes.  It loads these classes 
using the context class loader.  It appears this references the webapp class 
loader, hence the ClassCastException.  The session manager starts when I move 
[2] to /common/lib and delete [3].  However, since JavaGroups doesn't have the 
benefit of something like Catalina's CustomObjectInputStream and can't find the 
classes in my webapp, it fails while de-serializing objects.

It seems like it might be better to have JavaGroups favor the current class 
loader instead of the context class loader when the class exists in both, but 
why does it work in 4.0.3?

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>