Summary: | ClassNotFoundException when deserializing custom object with FileStore | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | mmalaidini |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | mmalaidini |
Priority: | P2 | ||
Version: | 5.5.27 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux |
Description
mmalaidini
2009-10-15 14:55:33 UTC
Check thread http://marc.info/?l=tomcat-user&m=125553788214052&w=2 at tomcat-user Same behavior observed when using tomcat 6.0.14 and 6.0.20. Is there any workaround for this problem? Correcting version as per issue description This works for me with a simple test web application. Re-reading your description and the users thread, it suggests the object has been created in one application but is being read by another. This is not a valid use case. This would explain why using the shared class loader allows this to work. If this isn't your use case, please feel free to re-open this bug and attach the simplest possible web application (with source) that demonstrates the issue so it can be investigated further. Are you running with a SecurityManager enabled? Note, that 1. org.apache.catalina.util.CustomObjectInputStream.resolveClass(..) does two attempts to load a class. First with webapp classloader, then with some other classloader (see ObjectInputStream.resolveClass(...), ObjectInputStream.latestUserDefinedLoader()). The exception that is logged comes from the second attempt. 2. webapp classloader throws ClassNotFoundException when java.security.AccessControlException is encountered when loading a class I changed exception handling in CustomObjectInputStream#resolveClass(..) in trunk r920912 and proposed for 6.0 and 5.5. If you will be able to reproduce this issue, please let us know. Exception handling fix applied to 5.5, will be in 5.5.29 onwards. I came across the code change for this (http://svn.apache.org/viewvc?view=revision&revision=920912) doing some pre-upgrade analysis and am wondering what information from the first exception (that was being hidden until this change) was more useful than the secondary exception? We've got a similar class in our application to accomplish the same basic goal and are considering doing the same fix to our class but want to understand the benefit/impact a little more. The community might benefit from this info being attached to this record as well (thus I'm posting here rather than in a forum area). Thanks! |