Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.2.2
-
Fix Version/s: 1.4.5
-
Component/s: None
-
Labels:None
Description
When trying to serialize pure XML conforming to a strict DTD, no extra attributes should be written.
The issue below forces me to rename fields:
@XstreamAlias("a")
public class A {
private String foo="bar";
}
public class B extends A {
@XstreamOmitField
private Integer foo; // could be String aswell, doesn't matter
}
Serializing an instance of B will create <a><foo defined-in="a">bar</foo></a>.
Since B.foo is not conflicting with a.foo, as it's not written or read, the 'defined-in' is unnecessary.
The fix would be in AbstractReflectionProvider around line 89; perhaps the simplestfix is to change
the return sig for writeField on line 94 to boolean and return false if the mapper.shouldSerialize* returns false,
then don't add the field to seenFields on line 98.
Since the recursion seems to go up, when the field B.foo is not marked in the seenFields map,
the writing of A.foo won't include that defined-in attribute.
For now, the workaround I use is to rename B.foo, though since A.foo is private it's not obvious this is a problem
until the XML is examined.
(PS: sorry I didn't write a patch - I usually do; this is a simple fix but if you really want a patch I can go through the trouble of checking out the code etc.. )
Activity
After restructuring the unmarshalling code of the ReflectionConverter, this feature could be implemented now.
Jörg Schaible
added a comment - After restructuring the unmarshalling code of the ReflectionConverter, this feature could be implemented now. 
Hi Kenny,
unfortunately it is not that simple. With XStream 1.2.2 you have the ability to define the order the fields are written yourself. Even more, with XStream 1.3 the default order will change (as already announced with the last release), inherited fields are written first (especially since this is also required if you use derived types in an XML schema). Therefore you would have to check, whether all other fields with the same name (note, there might be more than two) are ignored.
However, I found a solution to omit the defined-in attribute at serialization time (by setting more correct values into the defaultFieldDefinition map and the assumption that the field sequence is the same used for serialization and deserialization), but then XStream will badly fail to deserialize the XML, since it has no clue about which declared field of same name must be used in first place. XStream uses here currently some kind of default: Either the element has this defined-in attribute or it assumes that it is the first visible element. This default behaviour manifests unfortunately at some places. Therefore it's a bit complex and the code is brittle now after adding a lot of special handling to support all the different features. :-/
I will keep a deactivated unit test for now in the OmitField acceptance test, but realistically we can support this only after doing some major code clean-up in the core functionality.