Thanks Jorg !!
On Thu, May 2, 2013 at 3:48 PM, Jörg Schaible <[email protected]>wrote: > 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 > > >
