Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » unmarshalling issue (different java versions)
icon5.gif  unmarshalling issue (different java versions) [message #1123425] Wed, 02 October 2013 14:51 Go to next message
Juri A. is currently offline Juri A.
Messages: 5
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.
Re: unmarshalling issue (different java versions) [message #1124446 is a reply to message #1123425] Thu, 03 October 2013 14:44 Go to previous messageGo to next message
Judith Gull is currently offline Judith Gull
Messages: 52
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.
Re: unmarshalling issue (different java versions) [message #1139239 is a reply to message #1124446] Tue, 15 October 2013 16:34 Go to previous messageGo to next message
Juri A. is currently offline Juri A.
Messages: 5
Registered: October 2010
Junior Member
Hi Judith,

thanks for your response.

We came up with a different approach, which we believe should fix the problem as well.
We introduced a new class which extends RemoteServiceAccessPermission. This class overrides the method newPermissionCollection() of the parent class and instead of returning null an empty PermissionCollection structure
similar to IBMs java.security.PermissionsHash implementation is returned. The idea is to use a permission collection type which is known and common at both sides. This way we believe to avoid serialization issues.

The internal tests were promising. Now we wait, until we can verify it in the customer's test environment.

Best regards,
Juri.
Re: unmarshalling issue (different java versions) [message #1140787 is a reply to message #1139239] Wed, 16 October 2013 16:02 Go to previous message
Judith Gull is currently offline Judith Gull
Messages: 52
Registered: February 2010
Member
Hi Juri
I'm glad it works. Thanks for sharing!
Previous Topic:Client Downgrade with F2 Updater
Next Topic:AbstractSqlLookupService cancels transaction on PostgresSQL 9.2
Goto Forum:
  


Current Time: Thu Oct 02 04:37:11 GMT 2014

Powered by FUDForum. Page generated in 0.03035 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software