Thanks for the detailed explanation, Jörg.
I already had the HibernateMapper and HibernateProxyConverter set up.
I decided to get rid of the aliasing, as you suggested, and instead of tweaking
the default implementation (which was not helping), I overwrote the
CompactWriter, making the addAttribute() a do nothing. Both marshalling /
unmarshalling work fine, and the intermediate xml output on the stream is just
the way I wanted. (I use the NO_REFERENCES mode.)
> To: [email protected]
> From: [email protected]
> Date: Wed, 2 May 2012 11:37:35 +0200
> Subject: [xstream-user] Re: get rid of class="list" for more than one
> contained List interface fields
>
> Hi Amit,
>
> Amit Basu wrote:
>
> >
> > I have a container class as follows:
> > class FruitBasket { List<Apple> apples; List<Orange> oranges;}
> > I have added xstream.registerConverter(new
> > HibernatePersistentCollectionConverter(xstream.getMapper()));
>
> You should also setup the HibernateMapper and the HibernateProxyConverter.
>
> > I have also
> > setup alias apple for com.myorg.Apple and com.myorg.Orange. The marshalled
> > FruitBasket object has:
> > <apples class="list"> <apple>....</apple>
> > <apple>....</apple></apples><oranges class="list"> <orange>....</orange>
> > <orange>....</orange></oranges> In order to get rid of the class="list" in
> > apples and oranges, I added xstream.alias("apples", List.class,
> > PersistentList.class);xstream.alias("oranges", List.class,
> > PersistentList.class);
>
> A call to
> xstream.alias(name, type, defaultType)
> is only a shortcut for
> xstream.alias(name, type)
> xstream.defaultImplementation(type, defaultType)
>
> So what you effectively have defined is
> 1/ List.class should no longer be named "list", but "apples" now
> 2/ For serialization use every time the type List.class if a
> PersistentList.class is used; for deserialization use everytime a
> PersistentList.class if a List.class occurs
> 3/ List.class should no longer be named "apples", but "oranges" now;
> actually clobbering (1)
> 4/ Repeat definition of (2)
>
> > The objects are marshalled all right, without the
> > class= attributes. But the client unmarshals, and fails with
> > com.thoughtworks.xstream.mapper.CannotResolveClassException: oranges If I
> > change the order of aliasing with oranges first instead of
> > apples:xstream.alias("oranges", List.class,
> > PersistentList.class);xstream.alias("apples", List.class,
> > PersistentList.class); then the CannotResolveClassException comes for
> > apples.
>
> As said, they are clobbering each other. Additionally the alias definition
> is completely useless, since the names of the elements of FruitBasket are
> derived from the name of the fields and not from the type of the objects
> that are present in the field.
>
> > Seems like at most one collection of the same interface type (List
> > in this case) is end-to-end marshalled / unmarshalled all right for the
> > FruitBasket container class. I would like to know if there is a way around
> > the problem.
>
> Stays the call to defaultImplementation. As explained, the current
> definition is problematic, because at deserialization time it will try to
> instantiate a PersistentList. You may use the following sequence:
>
> xstream.defaultIMplementation(List.class, PersistentList.class);
> xstream.defaultIMplementation(List.class, ArrayList.class);
>
> The second call will actuall clobber the definition for deserialization.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
