Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.4.4
-
Fix Version/s: None
-
Component/s: Annotations
-
Labels:None
Description
XStream autoamtically skips transient fields. Where I use both Java serialization and XStream, I want to be able to mark certain fields such that Java serialization ignores it but XStream won't.
This patch adds an annotation to do this.
Activity
Hi Kohsuke,
with this patch you have an elegant solution for this problem, but it is unfortunately not the way we got in XStream. Annotations should always trigger functionality that is configurable with the XStream facade, because not everyone wants to have a hard reference to XStream in the projects model nor do you always control the classes where you would like to add the annotation.
However, for the upcoming release I'd simply expose the test for a transient field by moving the condition from the nested code part in method visitSerializableFields into method fieldModifiersSupported. That way you can then overload this method only by a derived ReflectionConvertor implementation.
Would that be enough for now to use a stock XStream release?
Jörg Schaible
added a comment - Hi Kohsuke,
with this patch you have an elegant solution for this problem, but it is unfortunately not the way we got in XStream. Annotations should always trigger functionality that is configurable with the XStream facade, because not everyone wants to have a hard reference to XStream in the projects model nor do you always control the classes where you would like to add the annotation.
However, for the upcoming release I'd simply expose the test for a transient field by moving the condition from the nested code part in method visitSerializableFields into method fieldModifiersSupported. That way you can then overload this method only by a derived ReflectionConvertor implementation.
Would that be enough for now to use a stock XStream release? Come to think of it, PureJavaReflectionProvider.fieldModifiersSupported() is already protected, so I suppose I can just define a subtype and push my logic in there.
In the end, all I care is that there is the funtionality of XStreamSerializable, so in a long run it'd be great if you implement that feature properly by "triggering functionality that is configurable with the XStream facade."
Kohsuke Kawaguchi
added a comment - Come to think of it, PureJavaReflectionProvider.fieldModifiersSupported() is already protected, so I suppose I can just define a subtype and push my logic in there.
In the end, all I care is that there is the funtionality of XStreamSerializable , so in a long run it'd be great if you implement that feature properly by "triggering functionality that is configurable with the XStream facade." 
The patch. My apologies for the lack of class comment in the annotation.