Eclipse Community Forums: scout » unmarshalling issue (different java versions)

Help

Home

Home » Eclipse Projects » scout » unmarshalling issue (different java versions)

Show: Today's Messages :: Show Polls :: Message Navigator

unmarshalling issue (different java versions) [message #1123425]

Wed, 02 October 2013 10:51

Juri Albert
Messages: 2
Registered: October 2010

Junior Member

Hi,

we have observed an issue with communication between server and client sides of a scout based application when both sides use different Java versions (IBM JDK 1.6 on server and Oracle Java 6 on client).
In our case Scout version 3.8.2 is used.

In client application following exception is thrown:

Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot deserialize object with new readObject()/writeObject() methods
---- Debugging information ----
class : java.util.Hashtable
required-type : java.security.PermissionsHash
path : /org.eclipse.scout.rt.shared.servicetunnel.ServiceTunnelResponse/m_data/java.security.Permissions/default/perms/entry[45]/java.security.PermissionsHash
line number : 1377
-------------------------------
at com.thoughtworks.xstream.converters.reflection.SerializableConverter.doUnmarshal(SerializableConverter.java:270)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:150)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:81)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:55)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:75)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:59)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:77)
at com.thoughtworks.xstream.converters.collections.MapConverter.populateMap(MapConverter.java:79)
at com.thoughtworks.xstream.converters.collections.MapConverter.unmarshal(MapConverter.java:66)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:81)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:55)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:75)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:59)
at com.thoughtworks.xstream.converters.reflection.SerializableConverter$2.readFieldsFromStream(SerializableConverter.java:317)
at com.thoughtworks.xstream.core.util.CustomObjectInputStream.readFields(CustomObjectInputStream.java:172)
at java.security.Permissions.readObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callReadObject(SerializationMethodInvoker.java:84)
... 25 more

It seems the problem occurs when client tries to deserialize server's response with permissions.
Since internally java.security.Permission* classes are used to keep information about permissions, client tries to unmarshal the XML blocks into the corresponding classes.
This works well with permissions lists which are kept in java.security.BasicPermissionCollection data structure, until one of the blocks uses PermissionsHash for permissions:

<entry>
<java-class>org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission</java-class>
<java.security.PermissionsHash>
<readOnly>false</readOnly>
<perms>
<entry>
<org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission>
<name>*.shared.*#*</name>
</org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission>
<org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission reference="../org.eclipse.scout.rt.shared.security.RemoteServiceAccessPermission"/>
</entry>
</perms>
</java.security.PermissionsHash>
</entry>

While processing this block the above exception is thrown from xstream library.

We compared the definition of PermissionsHash on both Java versions and there are some differences.
In Oracle Java java.security.PermissionsHash is defined in the same class as java.security.Permissions
final class PermissionsHash extends PermissionCollection implements Serializable

In IBM Java java.security.PermissionsHash is defined in a separate class as
final class PermissionsHash extends PermissionCollection

Is this a known problem and what is the recommended way to deal with it?
Or is this a candidate for a bug report?

Best regards,
Juri.

Report message to a moderator

Re: unmarshalling issue (different java versions) [message #1124446 is a reply to message #1123425]

Thu, 03 October 2013 10:44

Judith Gull
Messages: 33
Registered: February 2010

Member

Hi

I have not heard of this problem yet. You can influence serialization/deserialization in the service tunnel with an IObjectReplacer. (see org.eclipse.scout.rt.shared.servicetunnel.ServiceTunnelObjectReplacer). Then you can create your own ServiceTunnelContentHandler instead of DefaultServiceTunnelContentHandler and overwrite createObjectSerializer with your new replacer.

In the client you set the content handler when the session is loaded

@Override
public void execLoadSession() throws ProcessingException {
HttpServiceTunnel tunnel = new HttpServiceTunnel(this, getBundle().getBundleContext().getProperty("server.url"));
tunnel.setContentHandler(new MyServiceTunnelContentHandler());
setServiceTunnel(tunnel);

and in the server you can set your own ServiceTunnelServlet with that content handler and register it in the plugin.xml.

I hope this helps. Please give us feedback, if you can solve this problem or ask again, if you need more help! Thanks.

Report message to a moderator

Previous Topic:	Accessing the Table Page from an Abstract Menu
Next Topic:	RAP Form Timer Refresh

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Oct 07 23:33:16 EDT 2013