Ulrich Kreher created XSTR-695:
----------------------------------
Summary: Not respecting Serializable specification leads to
classloader problems
Key: XSTR-695
URL: https://jira.codehaus.org/browse/XSTR-695
Project: XStream
Issue Type: Bug
Affects Versions: 1.4.2
Reporter: Ulrich Kreher
Assignee: Joerg Schaible
We are using OSGi (Equinox) with the following (simplified) scenario:
Plugin A has package AA (with a class AAA) and package AB (with a class ABA).
AAA is not serialisable, has a no-arg constructor and a field of type ABA.
Plugin B has a package BA with a class BAA. BAA extends AAA and implements
Serializable. Additionally it provides its own readObject and writeObject for
serialising the fields of AAA as specified by java.io.Serializable.
Equinox uses different classloaders for plugin A and B. Plugin A imports
package AA but not AB. This works fine with Java serialisation not using
XStream. This just calls the no-arg constructor of AAA which sets the field for
ABA appropriately calling the constructor of ABA. Since AAA and ABA are in the
same plugin, the classloader knows both classes.
When using XStream with the the SerializableConverter XStream wants to
deserialise all fields of the non-serialisable class AAA. Instead of just
calling the no-arg constructor of AAA it tries to instantiate ABA. Since
XStream runs in the context of the classloader of plugin B, instantiating ABA
fails since the package AB is not imported by plugin B.
Importing package AB is no option since this would make the imports of B highly
dependent of the implementation of AAA. In our real scenario AAA has more than
just one field depending on internal packages that are not imported by B.
Is this behaviour of XStream intended? It probably stems from
http://jira.codehaus.org/browse/XSTR-266
Using an own converter for BAA circumvents this problem. However, this can get
quite tedious when serialising a lot of classes from different plugins. A
generic SerializableConverter in XStream behaving just like
java.io.Serializable would be very helpful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
<hr/>
<p>
To unsubscribe from this list please visit:
</p>
<p>
<a
href="http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email</a>
</p>
