Hi John,
js wrote:
> <Jörg>
> Well, no. Not really. See, XStream is about Java object to XML *and back*,
> i.e. every example can also unmarshal.
>
> Therefore adjust the marshalling. If XStream generates the required XML
> format, it can also read it. It is a very tedious and annoying task to try
> it the other way round (you already found this out), because you never
> know - especially as starter - why XStream throws an exception or silently
> skips some elements.
> </Jörg>
>
> <me>
> Typically, the use cases will be objects->xml for use by 3rd party or
> xml->objects where inbound xml was created by a 3rd party. Unless i was
> simply persisting and reading unmodified serialized data, i would expect
> that the inbound and outbound xml is different and created/digested by
> applications that may not even be java.
Your expectation does not have any influence, how XStream works.
> i created (marshalled/serialized) some test xml as follows:
> Persons ps = new Persons();
> Person p1 = new Person();
> p1.setName("joe");
> s.getPersons().add(p1);
> Person p2 = new Person();
> p1.setName("blo");
> ps.getPersons().add(p2);
> System.out.println(xstream.toXML(ps));
>
> while i *try* to unmarshalled/deserialize as follows:
> XStream xstream = new XStream(new StaxDriver());
> stream.alias("persons", Persons.class);
> xstream.alias("person", Person.class);
> xstream.addImplicitCollection(Person.class, "person");
> etc.
>
> These seems to be a very different set of methods.
??
Sorry, but I don't understand your comment. With those methods you influence
the XML format that is written *and* read.
================ %< ===================
Persons ps = new Persons();
Person p1 = new Person();
p1.setName("joe");
s.getPersons().add(p1);
Person p2 = new Person();
p1.setName("blo");
ps.getPersons().add(p2);
XStream xstream = new XStream(new StaxDriver());
xstream.alias("persons", Persons.class);
xstream.alias("person", Person.class);
// next is useless, Person.class has no member person
xstream.addImplicitCollection(Person.class, "person");
String xml = xstream.toXML(ps);
System.out.println(xml);
assertEquals(ps, xtream.fromXML(xml));
================ %< ===================
Will work (proper equals() implementations implied). It simply does not yet
write XML in the format you'd like to read in the end.
> My problem is that i
> can't find adequate examples (or documentation) on how to use alias() and
> addImplicitCollection() methods when unmarshalling collections.
Again, there's no difference between marshalling and unmarshalling. The
question is, which part of the tutorial do you not understand?
http://xstream.codehaus.org/alias-tutorial.html
- Jörg
> </me>
>
> ---
>
> <Jörg>
> Why do you think the objects have to be POJOs?
> </Jörg>
>
> <me>
> My xml needs to get deserialized into objects and then those objects used
> by the application. Why not unmarshall directly into my existing POJOs
> instead of having to create a whole new set of "command" (abstraction)
> classes whose only difference is that their accessors/mutators are get(),
> add() instead of the POJO standard get(), set()?
XStream does not call any of the methods.
> Things are much cleaner if i can (un)marshall using a simple library and
> leave my domain unmodified (which is why i'm trying to avoid xstream
> annotations).
Personally, I don't use annotations either - for exactly the same reason.
However, why do you think you cannot read/write into your domain model?
That's what I normally do with XStream. Procedure is the same again: Write
your domain model objects as XML and then start to tweak the output.
> I questioned the requirement of get(), add() and collections as lists,
> because that is whats used in the examples and i thought maybe they were
> required.
The generic (reflection-based) converters will look for declared members
only. No methods or constructors required.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
