Hi,
I guess the difference is that in my case I'm looking for an easy and
clean way to store plugin configuration (which should be a simple
value object) to XML, not serialize the exact state and details of the
object. If the object contains a field declared as List<String> then
after serialization-deserialization I don't care what the list type is
(and neither should the plugin writer).
After a bit more thought I guess what I'm looking for is that whenever
there's a field declared as List/Set/Map or some other basic
collection interface, then it is serialized in the implicit format and
the object type is discarded. When reading such XML a default object
type is selected (e.g. ArrayList/HashSet/HashMap).
If a field of type MyExtendedList is encountered then the object type
would still need to be stored, since the default types would not be
compatible.
Is it possible to choose converters or serialization form based on the
declared field type?
Thanks.
Regards,
Sampo N.
On Sat, Mar 31, 2012 at 15:50, Jörg Schaible <[email protected]> wrote:
> Hi,
>
> Sampo Niskanen wrote:
>
>> Hi,
>>
>> I'm considering using XStream to serialize and deserialize plugin
>> configurations in OpenRocket, an open-source model rocketry software.
>> XStream looks nice for the job, as the plugin writer doesn't need to
>> do anything other than implement a configuration pojo, and XStream can
>> serialize it properly.
>>
>>
>> Is there any way to make all collections automatically implicit, and
>> without the type of the collection being defined? For example
>> serializing the following class:
>>
>> class PluginConfiguration {
>> private List<String> greetings = Arrays.asList("Hello", "World");
>> }
>>
>> by default produces:
>>
>> <testing.PluginConfiguration>
>> <greetings class="java.util.Arrays$ArrayList">
>> <a class="string-array">
>> <string>Hello</string>
>> <string>World</string>
>> </a>
>> </greetings>
>> </testing.PluginConfiguration>
>>
>> I tried extending CollectionConverter and adding the condition
>> "List.class.isAssignableFrom(type)" to the canConvert method, and
>> registering the converter at high priority. This results in the
>> following:
>>
>> <testing.PluginConfiguration>
>> <greetings class="java.util.Arrays$ArrayList">
>> <string>Hello</string>
>> <string>World</string>
>> </greetings>
>> </testing.PluginConfiguration>
>>
>> I'm not exactly sure why this removed the <a> element from the middle
>> but hey
>
> In the first case the object was handled by the SerializableConverter, in
> the second case you registered a CollectionConverter for any object that is
> a List.
>
>> - that's what I want...
>
> Are you sure? If somebody provides a sorted list with a comparator, this
> comparator will now no longer be there after deserialization and the list
> will no longer keep its sort order. The CollectionConverter does not know
> about any additional class members of a Collection-derived type.
>
>> However it still contains the
>> class="java.util.Arrays$ArrayList" definition.
>
> Because that's what the object's type has been. XStream will by default
> always recreate the same object graph.
>
>> What I want is that
>> lists are serialized as lists without storing the exact list type, and
>> deserialized for example as an ArrayList.
>
> Exactly, this is *your* use case.
>
>> This is a compatibility issue as well, since it's not in any way
>> guaranteed that other JRE versions/implementations will even have a
>> class java.util.Arrays$ArrayList.
>
> Unlikely, because then you would also not be able to make a remote call with
> such an object as argument between the two JDKs. However, you could register
> an alias for "Arrays.asList(new Object[0]).getClass()".
>
>> Ideally I think the (de)serialization should be based on the field
>> type, not the actual object type.
>
> This would be a very bad idea:
>
> class Foo {
> Object s = "s";
> Object b = Boolean.TRUE;
> Object i = Integer.valueOf(3);
> }
>
> I bet you'd expect also the members containing the correct type after
> deserialization.
>
>> If the field is declared
>> "List<String>" then it should be serialized implicitly,
>
> BTW: An "implicit collection" is something completely different in XStream's
> context.
>
>> and any List
>> implementation can be used when deserializing (though a modifiable
>> list such as ArrayList is probably safest).
>
> And will happily drop silently class members ...
>
>> If the field has an
>> explicit type, then that should be used.
>
> Define "explicit type". There's only the field declaration type and the
> object type. And if the deserialization graph should be equal to the
> original one, XStream can only use the real type.
>
>> This seems like a common use-case, but I haven't found any discussion
>> about it. Is it possible to implement a converter that does this?
>
> You already created the converter and you can use XStream.aliasType to map
> any List type to "list". As long as you're aware of the consequences and
> realize that this is a solution only for a specific use case (that might
> match yours), it's OK.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
