Details
-
Type:
Improvement
-
Status:
Closed
-
Resolution: Duplicate
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
Guessing you'll either want to add more to this patch or you'll chose to apply only part of the patch course applying none of it is a distinct possibility 
Anyway, this patch does three things really:
Simple extra constructor to XStream to allow for just a Mapper to be passed in.
Allows shouldSerializeMember methods to evaluate the value of the field rather than just the aliasName[1] and definedIn.
Mapper for optionally skipping empty collections. If you choose to take this, you may want it to be configurable on field basis. Happy to add that or anything else you want.
[1] BTW, did you know the parameter names typically used for shouldSerializeMember are wrong. It's signature is typically (Class definedIn, String fieldName), when in fact the only place to invoke it in a non delegated fashion (AbstractReflectionConverter) actually passes in aliasName in leu of fieldName. Not sure if there is something I am missing.
Issue Links
Activity
I see that now. Only after digging around in the code and implementing what I thought was would be a new ability for XStream to reuse any collections instance created in field declarations or constructors did I realize...no initialization occurs at all as XStream uses the secret serialization constructor. That change caught me by surprise I had submitted a patch to Joe for what you now call implicit collections about two years ago and it was definitely not the case then.
I'll keep thinking about it.
David Blevins
added a comment - I see that now. Only after digging around in the code and implementing what I thought was would be a new ability for XStream to reuse any collections instance created in field declarations or constructors did I realize...no initialization occurs at all as XStream uses the secret serialization constructor. That change caught me by surprise I had submitted a patch to Joe for what you now call implicit collections about two years ago and it was definitely not the case then.
I'll keep thinking about it. The patch in XSTR-308 (http://jira.codehaus.org/browse/XSTR-308) is a better solution than the hack attached to this jira. Closing this one down as duplicate in favor of that item.
David Blevins
added a comment - The patch in XSTR-308 ( http://jira.codehaus.org/browse/XSTR-308 ) is a better solution than the hack attached to this jira. Closing this one down as duplicate in favor of that item. 
Hi David,
the only reason I did not resolve this issue with "won't fix" is, that you address more than the empty collection with this issue. Regarding your empty collection mapper I don't think this is a valid solution, since XStream can no longer distinguish at deserialization time, wether the collection was empty or null. Even worse it will be initialized with null. We might revisit such a functionality when we start to support XSTR-76 and XSTR-248 which are somewhat related. Resolving those issues, we might have also the need for passing the real object along with the type to shouldSerializeMember.
[1] Thanks for heads-up. In fact this is currently just by chance, since the aliasing was added at a later development stage.