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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
