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.
- 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.