[
https://jira.codehaus.org/browse/XSTR-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294586#comment-294586
]
Ulrich Kreher commented on XSTR-695:
------------------------------------
In this case you cannot do anything about this. However, it would help us a lot
to make SerializableConverter more extensible. We extended it for a
class-specific converter which omits the parent serialisation and calls the
constructor explicitly. Unfortunately, we needed to copy half of
SerializableConverter due to its (constant!) fields and methods being private
as well as its its usage of anonymous inner classes. If it helps, we can
propose a refactored SerializableConverter that fits our needs regarding
extensibility.
> 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>
