[
https://jira.codehaus.org/browse/XSTR-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294588#comment-294588
]
Joerg Schaible commented on XSTR-695:
-------------------------------------
The functionality to handle Serializable instances *is* fragile, just as you
already have learned. Therefore we are not very keen to expose a lot more entry
points. Again, did you try an instance of the SerilizationProvider using a
PureJavaReflectionProvider? This should solve the initialization problem for
you with the constructors. As sole concession we can declare
marshalUnserializableParent as protected to prevent any of these fields written
in an derived converter.
You might also be interested in XSTR-670 for a more global approach in an OSGi
environment.
> 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>
