[
https://jira.codehaus.org/browse/XSTR-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294854#comment-294854
]
Ulrich Kreher commented on XSTR-695:
------------------------------------
I understand your concern in not exposing too much of the serialisation. But
without this, one is forced to copy most of the class when extending it. This
is as bad if not worse: If you change something in the rather fragile
serialisation, one has to take care of adapting the own copied extensions.
However, declaring marshalUnserializableParent protected would help us a lot.
This is exactly what we are skipping in our solution.
Unfortunately, with the PureJavaReflectionProvider XStream still tries to load
the field type of an unmarshable parent. But due to OSGi plugin constraints it
cannot access this class (ABA, see above).
The global approach of XSTR-670 might help, but currently looks a bit overkill
to me. However, it would probably render the class-specific serialisation
unnecessary which we are using now to circumvent the problem.
> 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>
