XStream

AppEngine Compatibility.

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major 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.

  1. faster_safer.patch
    16/Apr/09 12:52 PM
    10 kB
    Paul Hammant
  2. gae3-xstream.patch
    02/Aug/09 10:52 PM
    4 kB
    Sean Sullivan
  3. gae4-xstream.patch
    01/Dec/09 1:23 AM
    4 kB
    DEWITTE Pierre-Alban
  4. gae-xstream.patch
    30/Jun/09 7:07 AM
    12 kB
    Paul Hammant
  5. gae-xstream2.patch
    01/Jul/09 11:16 AM
    9 kB
    Paul Hammant

Issue Links

Activity

Hide
Joerg Schaible added a comment -

Paul, I think this was the wrong patch. IMHO the second one, you've sent to the list makes this one obsolete anyway.

Show
Joerg Schaible added a comment - Paul, I think this was the wrong patch. IMHO the second one, you've sent to the list makes this one obsolete anyway.
Hide
Paul Hammant added a comment -

gae-xstream.patch -

Adds AppEngineXStream.java
Refactors XStream a little (more to follow if generally approved)

Thoughts?

Show
Paul Hammant added a comment - gae-xstream.patch - Adds AppEngineXStream.java Refactors XStream a little (more to follow if generally approved) Thoughts?
Hide
Paul Hammant added a comment -

gae-xstream2.patch

same idea, refactored to mean less code in subclass

Show
Paul Hammant added a comment - gae-xstream2.patch same idea, refactored to mean less code in subclass
Hide
Sean Sullivan added a comment -

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) ?

Show
Sean Sullivan added a comment - 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) ?
Hide
Joerg Schaible added a comment -

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

Show
Joerg Schaible added a comment - @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.
Hide
Sean Sullivan added a comment -

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.

Show
Sean Sullivan added a comment - 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.
Hide
Barak added a comment -

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?

Show
Barak added a comment - 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?
Hide
Sean Sullivan added a comment -

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

Show
Sean Sullivan added a comment - 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
Hide
Joerg Schaible added a comment -

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

Show
Joerg Schaible added a comment - @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.
Hide
John Nichol added a comment -

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)

Show
John Nichol added a comment - 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)
Hide
Joerg Schaible added a comment -

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
Show
Joerg Schaible added a comment - 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
Hide
John Nichol added a comment -

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

Show
John Nichol added a comment - 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
Hide
DEWITTE Pierre-Alban added a comment - - edited

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

Show
DEWITTE Pierre-Alban added a comment - - edited 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
Hide
Thierry Boileau added a comment -

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

Show
Thierry Boileau added a comment - 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
Hide
Galoch added a comment -

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

Show
Galoch added a comment - 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
Hide
Tomasz added a comment -

Galoch, tried applying the patches as you've said to no avail. Could you attach the actual jar that works for you? Thanks!

Show
Tomasz added a comment - Galoch, tried applying the patches as you've said to no avail. Could you attach the actual jar that works for you? Thanks!
Hide
Rikard Elofsson added a comment -

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?

Show
Rikard Elofsson added a comment - 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?
Hide
Joerg Schaible added a comment -

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.

Show
Joerg Schaible added a comment - 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.
Hide
Rikard Elofsson added a comment -

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.

Show
Rikard Elofsson added a comment - 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.
Hide
Rikard Elofsson added a comment -

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

Show
Rikard Elofsson added a comment - 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
Hide
Bill Milligan added a comment -

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.

Show
Bill Milligan added a comment - 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.
Hide
Joerg Schaible added a comment -

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

Show
Joerg Schaible added a comment - @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 ...
Hide
Bill Milligan added a comment -

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

Show
Bill Milligan added a comment - @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.
Hide
Tomasz added a comment -

@Bill, I couldn't agree more!

Show
Tomasz added a comment - @Bill, I couldn't agree more!
Hide
Galoch added a comment -

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

Show
Galoch added a comment - 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
Hide
Ferran Maylinch added a comment - - edited

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

Show
Ferran Maylinch added a comment - - edited 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
Hide
Salvador Diaz added a comment -

@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

Show
Salvador Diaz added a comment - @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

People

Vote (12)
Watch (12)

Dates

  • Created:
    Updated: