Hi Ashish,
Ashish<deXter> chougule wrote:
> My problem is that there are domain objects used across multiple projects
> .
>
> There are few projects which require to convert these domain objects to
> XMLs. Each project needs to have its own format.
>
> I am a beginner with xstream and after going through the tutorials I think
> we can't do this using annotations.(please correct me if I am wrong)
>
> So I looked at the api provided by Xstream class (.alias(....)).
> I could manage to get different XML outputs from same object.
> But soon I landed on another problem which was what if someone in my team
> innocently changed the field name (the alias methods take a string ) that
> will break my XML generation. Can I put some kind of constrain so that
> the compiler could tell me if some thing is changed.(I know this is out of
> the scope of xstream but.. Would be great if someone could help me
> out..also I know setter getters would Change but again that will not
> guaranty that the string in the alias method would change )
>
> So please help me with this problem..
> How can I cleanly get this "multiple XML outputs from same class "
Well, you're asking different questions. Answering about the different XML
output first:
As usual, the solution depends on your case:
1/ If you want to produce different XML from the same object graph, you
should use different XStream instances that are configured differently.
2/ If you want to produce different XML for object of the same type in one
object graph, you can work with different local converters for the
individual instances.
The other question is, how can you ensure that the generated XML format of
persisted objects is stable over several revisions of your code? XStream is
very convenient in persisting arbitrary objects in XML, but large parts of
it are based on reflection and the internals of your implementation will be
reflected therefore in the generated XML. This is brittle concerning
multiple software releases - as you already found out! XStream is in this
regard no way better than Java serialization.
If you want to keep the XML over revisions, you should definitely use custom
converters for the persisted objects that do not use reflection - at least
for those types that contain user data, their structure might change over
time with changing requirements.
A custom converter can be often easily adjusted to read old and XML format
styles of an object at once. Personally I always add a constant revision
number to the root object that is read at unmarshalling time and stored in
the context so that any custom converter might access it to react
accordingly. Since a custom converter uses typically no reflection to access
the handled object, you will get normally compilation errors if someone
changes that class in an incompatible way.
However, you should really use proper unit tests that are executed as part
of the build process. Create small XML snippets that contain the different
aspects of your object graph and let it parse by the XStream instance. Use
the generated object to create XML again and compare the resulting XML. You
will normally be warned then if something significantly has changed.
- Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
