Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.3.1
-
Fix Version/s: None
-
Component/s: Converters
-
Labels:None
Description
I've been using this for a month now, and I am happy with it. Joe does not like it though, he suggests there is potential for race.
As suggested, I will try more permutations to register a PureJavaReflectionProvider exclusively & report back.
Attachments
-
- faster_safer.patch
- 16/Apr/09 12:52 PM
- 10 kB
- Paul Hammant
-
- gae3-xstream.patch
- 02/Aug/09 10:52 PM
- 4 kB
- Sean Sullivan
-
- gae4-xstream.patch
- 01/Dec/09 1:23 AM
- 4 kB
- DEWITTE Pierre-Alban
-
- gae-xstream.patch
- 30/Jun/09 7:07 AM
- 12 kB
- Paul Hammant
-
- gae-xstream2.patch
- 01/Jul/09 11:16 AM
- 9 kB
- Paul Hammant
-
$i18n.getText("admin.common.words.hide")
- xstream_src.zip
- 23/Feb/11 4:15 PM
- 16 kB
- Galoch
-
- xstream_src/AppEngineXStream.java 2 kB
- xstream_src/HarmonyReflectionProvider.java 5 kB
- xstream_src/JVM.java 10 kB
- xstream_src/XStream.java 71 kB
-
$i18n.getText("admin.common.words.hide")
- xstreamGae.jar
- 23/Feb/11 4:15 PM
- 853 kB
- Galoch
-
- META-INF/MANIFEST.MF 0.0 kB
- com/thoughtworks/.../XStreamException.class 1 kB
- com/thoughtworks/xstream/XStream$1.class 2 kB
- com/thoughtworks/xstream/XStream$2.class 2 kB
- com/.../XStream$InitializationException.class 0.7 kB
- com/thoughtworks/xstream/XStream.class 33 kB
- com/thoughtworks/.../AppEngineXStream.class 2 kB
- com/thoughtworks/xstream/XStreamer.class 3 kB
- com/.../MarshallingStrategy.class 0.6 kB
- com/.../InitializationException.class 0.7 kB
- com/thoughtworks/.../XStreamConverter.class 0.6 kB
- com/.../AnnotationProvider.class 1.0 kB
- com/thoughtworks/.../XStreamOmitField.class 0.4 kB
- com/.../XStreamAsAttribute.class 0.5 kB
- com/thoughtworks/.../XStreamImplicit.class 0.5 kB
- com/thoughtworks/.../XStreamConverters.class 0.5 kB
- com/.../XStreamImplicitCollection.class 0.5 kB
- com/.../AnnotationReflectionConverter.class 6 kB
- com/.../XStreamContainedType.class 0.5 kB
- com/thoughtworks/.../XStreamInclude.class 0.5 kB
- com/thoughtworks/.../XStreamAlias.class 0.6 kB
- com/thoughtworks/.../Annotations.class 0.8 kB
- com/.../MarshallingContext.class 0.3 kB
- com/thoughtworks/.../ConverterRegistry.class 0.2 kB
- com/.../ConversionException.class 4 kB
- com/.../SingleValueConverterWrapper.class 2 kB
- com/thoughtworks/.../ErrorWriter.class 0.3 kB
- com/.../SingleValueConverter.class 0.3 kB
- com/thoughtworks/.../ConverterLookup.class 0.2 kB
- com/.../UnmarshallingContext.class 0.5 kB
Issue Links
Activity
gae-xstream.patch -
Adds AppEngineXStream.java
Refactors XStream a little (more to follow if generally approved)
Thoughts?
gae-xstream2.patch
same idea, refactored to mean less code in subclass
I am trying to use XStream 1.4 SNAPSHOT jar on Google AppEngine. Creating an XStream object causes this:
Caused by: java.lang.SecurityException: java.lang.IllegalAccessException: Reflection is not allowed on private java.lang.String java.text.AttributedCharacterIterator$Attribute.name
at com.google.apphosting.runtime.security.shared.intercept.java.lang.reflect.Field_.setAccessible(Field_.java:156)
at com.thoughtworks.xstream.converters.reflection.FieldDictionary.buildMap(FieldDictionary.java:147)
at com.thoughtworks.xstream.converters.reflection.FieldDictionary.fieldsFor(FieldDictionary.java:75)
at com.thoughtworks.xstream.converters.reflection.AbstractAttributedCharacterIteratorAttributeConverter.readResolve(AbstractAttributedCharacterIteratorAttributeConverter.java:83)
at com.thoughtworks.xstream.converters.reflection.AbstractAttributedCharacterIteratorAttributeConverter.<init>(AbstractAttributedCharacterIteratorAttributeConverter.java:52)
at com.thoughtworks.xstream.converters.extended.TextAttributeConverter.<init>(TextAttributeConverter.java:33)
at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:658)
at com.thoughtworks.xstream.XStream.<init>(XStream.java:437)
at com.thoughtworks.xstream.XStream.<init>(XStream.java:362)
at com.thoughtworks.xstream.XStream.<init>(XStream.java:348)
at foobar.internal.xstream.XStreamFactory$1.<init>(XStreamFactory.java:27)
at foobar.internal.xstream.XStreamFactory.createClientXStream(XStreamFactory.java:27)
Are there any plans to commit Paul Hammant's patch (gae-xstream2.patch) ?
@Sean: Did you see Paul's and my conversation on the dev list? Actually I don't like to add another specialized facade, but improve the runtime behaviour of the XStream facade itself. However, I don't know currently how I can detect that I am running GAE, since the environment identifies itself as standard Sun 1.6 JVM.
I examined Paul Hammant's patch (gae2-xstream.patch) and incoporated the code into a new patch.
Using my patch, I built a custom XStream jar and deployed it in an App Engine application. I have not found any problems (yet).
Please examine gae3-xstream.patch and let me know if the code is acceptable.
I'm tried the attached jar, and it failed on local development server. Trying to convert some JSF component to XML raised that:
java.security.AccessControlException: access denied (java.io.SerializablePermission enableSubclassImplementation)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:128)
at java.io.ObjectOutputStream.<init>(ObjectOutputStream.java:253)
at com.thoughtworks.xstream.core.util.CustomObjectOutputStream.<init>(CustomObjectOutputStream.java:58)
at com.thoughtworks.xstream.core.util.CustomObjectOutputStream.getInstance(CustomObjectOutputStream.java:33)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter.doMarshal(SerializableConverter.java:214)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshal(AbstractReflectionConverter.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshallField(AbstractReflectionConverter.java:157)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$2.writeField(AbstractReflectionConverter.java:148)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$2.visit(AbstractReflectionConverter.java:118)
at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:129)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doMarshal(AbstractReflectionConverter.java:100)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshal(AbstractReflectionConverter.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshallField(AbstractReflectionConverter.java:157)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$2.writeField(AbstractReflectionConverter.java:148)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$2.visit(AbstractReflectionConverter.java:118)
at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:129)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doMarshal(AbstractReflectionConverter.java:100)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshal(AbstractReflectionConverter.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at com.thoughtworks.xstream.converters.collections.MapConverter.marshal(MapConverter.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshallField(AbstractReflectionConverter.java:157)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$2.writeField(AbstractReflectionConverter.java:148)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$2.visit(AbstractReflectionConverter.java:118)
at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:129)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doMarshal(AbstractReflectionConverter.java:100)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.marshal(AbstractReflectionConverter.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63)
at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:98)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:38)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:841)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:830)
at com.thoughtworks.xstream.XStream.toXML(XStream.java:805)
at com.thoughtworks.xstream.XStream.toXML(XStream.java:793)
at com.me.jsf.QueryBeanV4.setUiData(QueryBeanV4.java:375)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.myfaces.el.PropertyResolverImpl.setProperty(PropertyResolverImpl.java:410)
at org.apache.myfaces.el.PropertyResolverImpl.setValue(PropertyResolverImpl.java:177)
at org.apache.myfaces.el.ValueBindingImpl.setValue(ValueBindingImpl.java:278)
at org.apache.myfaces.shared_impl.util.RestoreStateUtils.recursivelyHandleComponentReferencesAndSetValid(RestoreStateUtils.java:86)
at org.apache.myfaces.shared_impl.util.RestoreStateUtils.recursivelyHandleComponentReferencesAndSetValid(RestoreStateUtils.java:57)
at org.apache.myfaces.shared_impl.util.RestoreStateUtils.recursivelyHandleComponentReferencesAndSetValid(RestoreStateUtils.java:94)
at org.apache.myfaces.shared_impl.util.RestoreStateUtils.recursivelyHandleComponentReferencesAndSetValid(RestoreStateUtils.java:57)
at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:98)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:105)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:80)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:143)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:124)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:313)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Is there some configuration I missed in order to make xstream working with gae?
Jörg,
Have you had time to review the patch that I submitted on August 2nd?
https://jira.codehaus.org/secure/attachment/43548/gae3-xstream.patch
@Sean, yes I had a look, that's exactly what I had in mind in first place. It's just that I am currently in the middle of the work for a different area of XStream and I had no time to come back to GAE compatibility. The only thing that itches me still is, that this looks all like a standard environment with a SecurityManager similar using XStream in an applet. In this case it might be possible as alternative to check the runtime permissions in a general way. Barak's issue with the SerializationConverter makes me think about this alternative.
Any progress on this issue? I have patched 1.3.1-src download of XStream with the gae3-xstream.patch and it doesn't seem to work with app engine 1.2.5. The exception is below. Basically I am not allowed to create a CustomObjectInputStream due to permissioning issues.
I am attempting to parse an XML file containing a list of XStreamed data objects.
Thanks,
John
java.security.AccessControlException: access denied (java.io.SerializablePermission enableSubclassImplementation)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:139)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:303)
at com.thoughtworks.xstream.core.util.CustomObjectInputStream.<init>(CustomObjectInputStream.java:62)
at com.thoughtworks.xstream.XStream.createObjectInputStream(XStream.java:1501)
at com.thoughtworks.xstream.XStream.createObjectInputStream(XStream.java:1481)
at com.cloudscapesolutions.wavacalculator.server.UploadFileServlet.loadData(UploadFileServlet.java:71)
at com.cloudscapesolutions.wavacalculator.server.UploadFileServlet.service(UploadFileServlet.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:313)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Hi John,
as long as you cannot grant more permissions for an app on GAE, it is not possible to use the SerializationProvider nor will the XStream.createObjectInputStream/XStream.createObjectOutputStream work. However, this is nothing XStream can do about - except for not registering the SerializationConverter also.
- Jörg
- Jörg
Jörg,
I understand the problem and can see its not straightforward to fix.
In case its useful to anyone else I will point out that if its possible for your application if you change from using an Input/Output
stream approach with XStream and instead use toXml/fromXml on lists/sets of objects you can workaround the GAE security problem.
I assume you will still need to apply one of the patches attached to this case, I have tested with the gae3-xstream.patch and managed to
upload a list of objects created with xstream.toXml() and then converted back to objects in GAE with xstream.fromXml(inputStream) where the inputStream is a standard input stream obtained from an HTTPRequest.
Pity XStream and GAE can't work together better yet, hopefully as GAE evolves it will be possible. XStream is an incredibly useful library.
Cheers, John
Hi all,
I just improve the patch (file gae4-xstream.patch and xstream-1.4-SNAPSHOT-GAE.jar) for XStream 1.4 version. The jar attach to this issue is working in a GAE App.
Best regards
I've just tested the 1.4 patch, and I was unable to convert an XML representation to an object instance, having the following exception: java.lang.NoClassDefFoundError: sun.reflect.ReflectionFactory is a restricted class.
I'm using gae 1.3.
Best regards
Just for the record so other ppl can benefit ... the attached JAR file [xstream-1.4-SNAPSHOT-GAE.jar] does not work in GAE (tested on 1.3.1).
But, after applying gae-xstream2.patch and gae3-xstream.patch to the trunk I was able to successfully serialize (using toXml) and de-serialize (using fromXml) in GAE.
Different JAR versions on other sites also did not work for me out of the box especially when de-serializing.
Thanks
G
Please please someone upload a working jar somewhere or I have to spend next week switching to some crappy non-xstream solution for my GAE project... Please?
Guys, did anyone of you actually read what was written in this issue and what causes the problem? Neither did one of the contributors of the various patches use all available converters nor did the policy for the SecurityManager stay the same between the various GAE versions. Anything that has been done in all those patches are to prevent XStream from registering some of its default converters. Future versions of XStream will provide information for each converter what kind of policies it requires, before it is registered, but that's nothing that will be available in the next weeks.
And now maybe you better start to think yourself before you apply blindly any arbitrary patch that is somewhere available. All you have to do is to derive from XStream, overload the setupConverter method and register only those converters you actually use and that can be executed in the GAE environment.
BTW: I've seen none of you guys on the user's list asking a simple question for GAE. This here is definitely not a forum for discussion, so please stop it.
OK will stop, never been on the forum no, recently fallen in love with XStream and want to keep using it in GAE environment thats all. Didnt want to look stupid or rude. Simply extending XStream and overriding setupConverters does not
work since dynamicallyRegisterConverter is a private method. I suppose building from source could work, trying that now.
And yes it works. I am on Windows using Eclipse plugin GAE 1.3.3.1. I only had to comment out "registerConverter(new TextAttributeConverter(), PRIORITY_NORMAL);" and after that it works. Sorry for the waste of bandwidth before
There's an additional problem running in GAE/J 1.3.4 having to do with Serializable objects with readObject() or writeObject() semantics included, such as most Java collections. I locally patched SerializationMethodInvoker to understand that a SecurityException on trying to access "writeObject()" or "readObject()" means they are unsupported, even if that means these private methods are unsupported only on GAE/J. The more I looked at it however, I realized I shouldn't even be hitting the SerializableConverter for my implementation.
Further, a problem that may crop up not just on GAE/J, but many other ORMs such as Hibernate, is that CollectionConverter hardcodes accepted types. When DataNucleus populates a List with its own internal muckety-muck List implementation, CollectionConverter does not know how to cope, which is why I was erroneously running into the SerializableConverter above in the first place. I locally patched this such that the canConvert() method includes an extra catch-all expression: "|| java.util.Collection.class.isAssignableFrom(type)".
Since Joerg seems to dislike arbitrary patches from "somewhere" I shall not submit one – but the difficulties in getting XStream working these days is a little confusing. This ticket has been open for over a year with many nice suggestions for repair. What gives? I've long used and enjoyed XStream but I've got to confess, JAXB is starting to look a lot more attractive these days.
@Bill: I did not see you asking any questions on the user's list also. You mix up here two completely unrelated topics (Security stuff on GAE and Collections), try to patch something, that has been implemented this way for a reason the last nine years. Simply because you do not understand an implementation detail, fail to ask questions or even looking for an advice, you blame XStream? That does not look fair either ...
@Joerg, XSTR-566 appears to be a blanket ticket dealing with issues of AppEngine compatibility, or at least it is titled in such a fashion. I have delved deeply into your code and found things that need fixing. Perhaps you didn't understand the details of my original post. I recommend you re-read it for clarity. There is only one issue at stake: XStream does not work out of the box when deployed to GAE, in no small part because of odd GAE security model dealing with Reflection. I have made two suggestions for fixing this. I apologize if you aren't looking for solutions to problems with your code.
As an end client of XStream, I simply don't have the time to get embroiled in forum discussions. XStream is your passion. It is nowhere near the center of my coding world. I have other things to do with my time; I simply expect XStream to work, out of the box and as documented. When it doesn't work, I'm going to either file a ticket or append to an existing ticket. If you don't want people to make complaints when something that seems like it should work, doesn't work, then perhaps you should rethink even having a JIRA system in the first place. Stop taking it personally. No one is "blaming" you or XStream. It simply does not work the same way in GAE as it does in other environments. The concept of "fair" does not apply when you are in the business of moving electrons around. Either adapt your code, address a solution, or lose credibility in the marketplace.
If you have a better solution, then instead of moaning about how we don't contribute to your forum, why don't you post a solution here? Or perhaps even post a link to your forum that I frankly didn't even know existed?
BTW, I switched to JAXB. It works very nicely out of the box in GAE/J. That said, I'd still prefer to have the option of using XStream without having to hand-patch it.
Sorry guys ... I did not visit this thread after my last post until I got PM'ed today. So here is the JAR that worked for me. Word of caution: I tested it last on GAE version 1.3.1 and I am not using XStream anymore since my requirements have changed. In addition it won't include any changes to XStream that have been made since then.
Now the good news ... I still have the changes I made based on earlier comments. The modified files are attached in xstream_src.zip file. Again, they may be outdated but will give a fairly good idea where to make the changes.
Thanks,
galoch
Hello,
Sorry if this is a stupid question but I would really like to use XStream in the client side of GWT and I don't know how to do it. I added the JAR to my project but I suppose it is not that easy.
Could you help me?
Thank you very much,
Ferran
@Ferran Maylinch
Short answer: you can't use xstream in the client side of GWT.
Longer answer: GWT can't emulate java reflection on the client side (see http://code.google.com/intl/en-EN/webtoolkit/doc/latest/DevGuideCodingBasicsCompatibility.html and http://code.google.com/intl/en-EN/webtoolkit/doc/latest/RefJreEmulation.html ) so you won't be able to make Xstream work.
Also: this isn't the place to ask for such questions, they're completely unrelated to this Xstream issue and there are better places to do it (such as the gwt users google group or even the xstream forum)
Hope that helps
Paul, I think this was the wrong patch. IMHO the second one, you've sent to the list makes this one obsolete anyway.