[
https://jira.codehaus.org/browse/XSTR-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294916#comment-294916
]
Joerg Schaible commented on XSTR-695:
-------------------------------------
The method is protected now in trunk. AFAICS it should work now if you overload
marshalUnserializableParents with an empty method and overload
instantiateNewInstance with a version that creates an object of the required
type using its default constructor.
> 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>
