Hi Tamas,
Farago, Tamas wrote:
> Hi,
>
> I am evaluating using XStream for our project and have run into the
> issue of adding text-content to XM using latest version of XStream,
> 1.4.4. It doesn't matter if I use the built-in XPP or the StaxDriver,
> they both have the same result.
>
> I have the following simple snippet I want to convert:
>
>
> Enum Symbology {RIC, ISIN}
>
>
> @XStreamAlias("Underlying")
>
> @XStreamConverter(value = ToAttributedValueConverter.class, strings =
> {"Underlying"})
>
> public class UnderlyingView {
>
> @XStreamAsAttribute public Symbology symbology;
>
> public String Underlying;
>
> }
>
>
> Whenever I convert this to XML I get the following data. Obviously this
> is a very simple snippet of code (groovy actually), but this reproduces
> it for me:
>
> XStream xStream = new XStream()
>
> UnderlyingView un = new UnderlyingView([symbology: "RIC", Underling:
> "underlying1"])
>
> String result = xStream.toXML(un)
>
>
> Output::
>
> <?xml version="1.0" ?><Underlying>RICunderlying1</Underlying>
>
>
> The text content is all fine, however the attribute, which is an enum is
> lost, and merged into the text node.
>
> Why is this? I do want to note that if I create a custom converter for
> UnderlyingView where I marshal/unmarshal this class myself it works of
> course. But I'd rather go without the custom converter :)
Can you open a JIRA issue, please? Your xircles account for this ML is the
same for JIRA. Enums are handled specially in XStream and it seems there's
something lost in this converter.
> Additionally, would it be possible to change the API for text content?
> It looks overly complicated, an annotation like @XStreamAsText in front
> of the text value would be a lot easier; e.g. like SimpleXML, they just
> annotate with @Text and it works. That framework has other problems so
> for us XStream would be a better match.
We used an (existing) annotation at class level, because when you annotate
the field, you make also decisions for derived classes which might be out
of
your control. Especially it is possible that this converter cannot handle a
derived class at all because of new complex members. Or you might derive
from a class out of your control that contains the field that should be
used
as tag value.
> I would also like to point out that on the FAQ the statement about
> "fields are serialized in the order of declaration" is incorrect. The
> JVM does not give you any guarantee about the order it returns you the
> fields during reflection, so if you want to ensure a particular order
> you have to code it yourself.
In the last 10 years we found two types of JDKs: The ones that serialize in
declaration order and the ones that reverse the order (older ones from
IBM).
However, it is not the JVM, but the compiler that defines the order, so it
depends on the JDK that was used to create the class files.
So, you are technically right, but at least I do currently not know any
compiler that does it not in declaration sequence.
However, if you sort the elements yourself, you may run into trouble if you
do not write and read the fields of a parent class first.
- Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
