All, Here is a patch which allows xstream to run inside of unsigned applets with increased security restrictions. 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 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() Thanks for the great work on xstream and let me know if you will (or will not) consider applying this patch. Recently switched from XMLEncoder and this issue is holding up the next release of one of my libraries. - Peter -- "Now, now my good man, this is no time for making enemies." — Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan.
