Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: 1.4.4
-
Fix Version/s: 1.4.5
-
Component/s: Compatibility
-
Labels:None
-
JDK version and platform:Oracle 1.6 Linux
Description
Currently xstream cannot be used inside of (unsigned) applets because it causes an exception to be thrown when a ClassLoader is created. Looks like this issue has come up a couple of times in the past. The patch is fairly simple and only took a couple of hours to code up and test. What the patch does is that it replaces all references to ClassLoader with a new XStreamClassLoader interface. There is now no need to create a new instance of ClassLoader, which is what caused the security exception.
All unit tests pass. I don't believe that any additional unit tests are required since it's mostly a modification of existing code instead of adding new classes.
To actually work inside of the applet the user does need to create a custom XStreamClassLoader, which uses reflections to load Class, and use PureJavaReflectionProvider. Some obscure serialization issues still can't be handled inside of applets, but I have yet to encounter those in my application. If requested I can post an example of how to do this too.
Potential issue:
- Take a look at CompositeClassLoader. It passes all tests but I'm uneasy about how I implemented getClassLoader()
- This patch does break backwards compatibility since ClassLoaderReference no longer extends ClassLoader. The patch could be redesigned so that ClassLoaderReference is not modified, at the cost of some code bloat.
- If backwards compatibility is being totally discarded then XStream's constructors can be cleaned up a bit.
Activity
Thanks for the contribution. I took a similar approach and kept anything backward compatible, since upcoming release should be a drop in. Available in trunk.
Jörg Schaible
added a comment - Thanks for the contribution. I took a similar approach and kept anything backward compatible, since upcoming release should be a drop in. Available in trunk. 
Found a "minor" unintended consequence. In XStream.setupConverters() two lines are surrounded by try{}catch{}. DynamicProxyConverter and TextAttributeConverter blow up when run as an applet due to AccessControlException being thrown inside their static{} initializers. With the current patch the code runs fine once, but the second time XStream is called it fails. I further modified the code such that it catches AccessControlException inside their static{} and ignores it. Works well for my application, but I'm not sure about others. I'm guessing that if you needed that functionality you would end up with some random null pointer exception and have absolutely no idea what went wrong. Again, this is only an issue when run inside an applet.