Details
-
Type:
Bug
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.2
-
Component/s: None
-
Labels:None
-
JDK version and platform:Sun 1.4.2_09 for Windows
Description
XStream generates bad XML of Class1 has a transient field class2 of type Class2 and has a custom writeObject() method that writes class2 before calling defaultWriteObject(). Class2 has a custom writeObject() method that simply calls defaultWriteObject(). The default section for Class1duplicates the default section for Class2 rather than the declared fields of Class1.
I wasn't sure how to generate a JUnit test for this, but I've attached a simple, stand-alone Java file with a simple test case that writes the XML to System.out.
Activity
Here is a proposed TestCase and a proposed draft version of a patch. If fixes the XSTR-245 but additional test cases should be added.
The main idea of the patch is to use a stack of callBacks in CustomObjectInputStream and CustomObjectOutputStream instead of the previous version that only hold the current callback.
Cyrille Le Clerc
added a comment - Here is a proposed TestCase and a proposed draft version of a patch. If fixes the XSTR-245 but additional test cases should be added.
The main idea of the patch is to use a stack of callBacks in CustomObjectInputStream and CustomObjectOutputStream instead of the previous version that only hold the current callback. Final version of a proposed patch.
Main idea :
Use a stack of StreamCallbacks in CustomObjectInputStream and CustomObjectOutputStream instead of the previous version that only hold the current streamCallback.
Comments:
Even if this bug was related to SerializableConverter, I modified ExternalizableConverter to apply the same pattern.
Modified files :
- CustomObjectInputStream and CustomObjectOutputStream to add these stacks
- SerializableConverter doMarshal and doUnmarshal to call popCallback()
Note that pushCallback is not called by SerializableConverter but by CustomObjectOutputStream#getInstance - ExternalizableConverter same modifications as for SerializableConverter
Created files :
- SerializationNestedWriteObjectsTest testcase in the acceptance package
Tests and build:
Patch was developped against subversion trunk #866. All the tests passed successfully and ant build succeeded
Cyrille Le Clerc
added a comment - Final version of a proposed patch.
Main idea :
Use a stack of StreamCallbacks in CustomObjectInputStream and CustomObjectOutputStream instead of the previous version that only hold the current streamCallback.
Comments:
Even if this bug was related to SerializableConverter, I modified ExternalizableConverter to apply the same pattern.
Modified files :
CustomObjectInputStream and CustomObjectOutputStream to add these stacks
SerializableConverter doMarshal and doUnmarshal to call popCallback()
Note that pushCallback is not called by SerializableConverter but by CustomObjectOutputStream#getInstance
ExternalizableConverter same modifications as for SerializableConverter
Created files :
SerializationNestedWriteObjectsTest testcase in the acceptance package
Tests and build:
Patch was developped against subversion trunk #866. All the tests passed successfully and ant build succeeded I've applied a slightly modified patch of Cyrille. Cyrille & Philip, does this work for you?
Jörg Schaible
added a comment - I've applied a slightly modified patch of Cyrille. Cyrille & Philip, does this work for you? It work successfully for me (svn revision 870).
Cyrille Le Clerc
added a comment - It work successfully for me (svn revision 870). 
This file contains the output from running the attached Class1.java. The XML for Class1's default section is wrong: it duplicates the default section for Class2.