Hi Jörg, Created the bug report:
http://jira.codehaus.org/browse/XSTR-732 I modified the patch and removed import simplifications that intellij did. When is the next major version "scheduled" approximately? Trying to figure out how to handle my serialization issues since Oracle broke backwards compatibility in 1.7 with XmlEncoder/XmlDecoder. If you are going to totally break backwards compatibility you could probably do things a bit cleaner than I did it. On the flip side, with additional work you could make that approach backwards compatible too, at the cost of code bloat and the need for more unit tests to handle edge cases. - Peter On Fri, Apr 12, 2013 at 8:25 AM, Jörg Schaible <[email protected]>wrote: > Hi Peter, > > Peter A wrote: > > > 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. > > I'll have a look at it. However, can you please open a JIRA issue and > attach > it there? And please, provide a patch that does not format part of the code > or restructures the import sections. Thanks. > > > 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. > > From what I've seen in the patch, your approach is very promising. The > current class loader design is one of the oldest parts of XStream and > unfortunately also part of the current API, so we cannot simply replace it, > but I have an idea for the next major version ... even if it means to > create > some deprecations ;-) > > Thanks, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- "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.
