Hi Thomas,
first: Please don't use an existing mail of the list to start a new thread.
Any sane mail client that supports threads will hide this conversation deep
down in an unrelated thread now. Search your mail here yourself to see the
result: http://xstream.codehaus.org/list-user.html
Thomas Fletcher wrote:
> I'm looking for some general design feedback.
>
> We are using xstream to serialize/unserialize java content as the most
> expeditious way to provide a persistent file format for a design model.
>
> Initially we didn't have any custom converters since there was no
> motivation to do so since the generic transforms worked great.
> Unfortunately now we are running into a situation where it would be
> desirable to have our own converters, but we still need to
> be able to convert the older model files.
>
> Is there a way to 'chain' converters such that I can behave sanely in the
> 'HELP' situation below I've presented below.
>
> Thanks,
> Thomas
> -----------------
>
> XStream xstream = new XStream(new Xpp3Driver() )
> xstream.registerConverter(new MyConverter())
>
> class MyConverter implements Converter {
> public Object unmarshal(HierarchicalStreamReader reader,
> UnmarshallingContext context) {
> //If this is something converted using the new style ... convert it and
> return
>
> //Otherwise: HELP! I don't want to fail here! =;-)
> }
> ...
> }
Actually there's no general solution. It depends on the use case.
Basically you could derive from the converter that did handle the old format
and (assuming the structure of the object did not change) you can then call
the parent class to deserialize it. However, here you have the problem, that
you have to switch before you read the first element or value.
Personally I define typically a version attribute for the root element. The
converter for the root element will look out for this attribute and save its
value in the unmarshalling context. Therefore I have later on access on the
version in any converter. You might even introduce such an attribute now and
set the version in the context to 0 if it is missing.
XStream itself has some converters that can read an format written by older
XStream versions e.g. the GregorianCalendarConverter (simple) or the
SerializableConverter (complex). However, these converters handle the old
format directly.
Another approach is more brute force: Keep an own XStream instance for the
old format. If the deserialization with the new instance fails, use the old
one (in case of an InputStream you have to set/reset a mark at the beginning
it obviously). When you also introduce the version attribute with the new
XML format, you can fail quite fast ;-)
Hope this gives you some ideas,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
