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
