JavaBeanConverter vs @XStreamAsAttribute

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JavaBeanConverter vs @XStreamAsAttribute

Lethal Possum
Hello everyone,

I am a new to XStream user and I have an issue that might be very simple but I am not able to figure it out.

Let's say I have the following XML:

<main id="foo">
   <name>bar</name>
</main>

I would like to use the JavaBeanConverter to force the unmarshalling to go through my setters but when I register the JavaBeanConverter, my XStreamAsAttribute annotations seem to stop working.

Here is my code so far:

import com.thoughtworks.xstream.XStream;
import com.thoughtworks.xstream.annotations.XStreamAlias;
import com.thoughtworks.xstream.annotations.XStreamAsAttribute;
import com.thoughtworks.xstream.converters.javabean.JavaBeanConverter;

@XStreamAlias("main")
public class Main {

    public static void main(String[] args) {
        XStream xstream = new XStream();
        xstream.autodetectAnnotations(true);
        xstream.registerConverter(new JavaBeanConverter(xstream.getMapper()), XStream.PRIORITY_VERY_LOW);
        xstream.processAnnotations(Main.class);
        System.out.println(xstream.fromXML("<main id=\"foo\"><name>bar</name></main>"));
    }

    @XStreamAsAttribute
    private String id;

    private String name;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        System.out.println("Called setId()");
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        System.out.println("Called setName()");
        this.name = name;
    }

    @Override
    public String toString() {
        return "Main [id=" + id + ", name=" + name + "]";
    }
   
}

With the JavaBeanConverter registered, I see the print message in setName() but not the one in setId() and the id field remains null. If I comment it out, I do not go through the setters but id's value is correct. What am I missing?

Thanks in advance for your help.

Cheers,

LP
Reply | Threaded
Open this post in threaded view
|

Re: JavaBeanConverter vs @XStreamAsAttribute

Jörg Schaible-4
Hello LP,

Lethal Possum wrote:

> Hello everyone,
>
> I am a new to XStream user and I have an issue that might be very simple
> but I am not able to figure it out.
>
> Let's say I have the following XML:
>
> <main id="foo">
>    <name>bar</name>
> </main>
>
> I would like to use the JavaBeanConverter to force the unmarshalling to go
> through my setters but when I register the JavaBeanConverter, my
> XStreamAsAttribute annotations seem to stop working.

[snip]

> With the JavaBeanConverter registered, I see the print message in
> setName() but not the one in setId() and the id field remains null. If I
> comment it out, I do not go through the setters but id's value is correct.
> What am I missing?

The current implementation for the attribute support (and other stuff) is
completely based on reflection. Therefore the JavaBeanConverter has
currently no support for attributes, since the property name of a bean does
not have to correspond in any way with the internal field name of a member
of the bean. Sorry.

Unfortunately this is nothing we can change in short time, since it requires
a most-probably incompatible redesign of the registration and lookup part.

> Thanks in advance for your help.

What do you try to achieve with the calling of the setters?

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: JavaBeanConverter vs @XStreamAsAttribute

Lethal Possum
Hello Jörg,

Thank you for your quick and clear answer.

I am trying to migrate an existing code base from JAXB to XStream, to compare the unmarshalling speed and the ease of use of both frameworks. Currently our JAXB annotations use the accessors. I wanted to do the same in XStream in case some of the accessors have some extra logic in it and also to make the benchmark as fair as possible.

I will review our accessors and if none of them do anything special, I guess accessing the fields directly is not a big issue.

Thanks again,

LP


On Thu, May 15, 2014 at 5:27 PM, Jörg Schaible <[hidden email]> wrote:
Hello LP,

Lethal Possum wrote:

> Hello everyone,
>
> I am a new to XStream user and I have an issue that might be very simple
> but I am not able to figure it out.
>
> Let's say I have the following XML:
>
> <main id="foo">
>    <name>bar</name>
> </main>
>
> I would like to use the JavaBeanConverter to force the unmarshalling to go
> through my setters but when I register the JavaBeanConverter, my
> XStreamAsAttribute annotations seem to stop working.

[snip]

> With the JavaBeanConverter registered, I see the print message in
> setName() but not the one in setId() and the id field remains null. If I
> comment it out, I do not go through the setters but id's value is correct.
> What am I missing?

The current implementation for the attribute support (and other stuff) is
completely based on reflection. Therefore the JavaBeanConverter has
currently no support for attributes, since the property name of a bean does
not have to correspond in any way with the internal field name of a member
of the bean. Sorry.

Unfortunately this is nothing we can change in short time, since it requires
a most-probably incompatible redesign of the registration and lookup part.

> Thanks in advance for your help.

What do you try to achieve with the calling of the setters?

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Re: JavaBeanConverter vs @XStreamAsAttribute

Jörg Schaible-4
Hi Lethal,

Lethal Possum wrote:

> Hello Jörg,
>
> Thank you for your quick and clear answer.
>
> I am trying to migrate an existing code base from JAXB to XStream, to
> compare the unmarshalling speed and the ease of use of both frameworks.

Well, I guess JAXB will process the XML faster, just because it uses
generated stubs to read/write the predefined XML. However, biggest drawback
is, that you will have to generate different stubs for different versions of
your schema and it gets even more difficult, if you have to process multiple
XML versions of your schema without knowing which one in advance. Here you
can provide custom converters in XStream that can read old and new format at
the same time.

> Currently our JAXB annotations use the accessors. I wanted to do the same
> in XStream in case some of the accessors have some extra logic in it and
> also to make the benchmark as fair as possible.
>
> I will review our accessors and if none of them do anything special, I
> guess accessing the fields directly is not a big issue.

One general advice: Instantiating an XStream instance and setting it up is a
very expensive operation. Therefore you should do this only once and then
reuse the prepared instance every time. You may use this instance even
concurrently since marshalling/unmarshalling is threadsafe.

If you have to optimize extremely for speed, you should create custom
converters for your objects instead of using the default ones based on
reflection. This will have a similar effect compared to the JAXB stubs.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: JavaBeanConverter vs @XStreamAsAttribute

Lethal Possum
On Fri, May 16, 2014 at 12:06 PM, Jörg Schaible
<[hidden email]> wrote:

>
> Hi Lethal,
>
> Lethal Possum wrote:
>
> > Hello Jörg,
> >
> > Thank you for your quick and clear answer.
> >
> > I am trying to migrate an existing code base from JAXB to XStream, to
> > compare the unmarshalling speed and the ease of use of both frameworks.
>
> Well, I guess JAXB will process the XML faster, just because it uses
> generated stubs to read/write the predefined XML. However, biggest drawback
> is, that you will have to generate different stubs for different versions of
> your schema and it gets even more difficult, if you have to process multiple
> XML versions of your schema without knowing which one in advance. Here you
> can provide custom converters in XStream that can read old and new format at
> the same time.
>
Indeed I have been burnt by this issue with JAXB many times in the
past in projects where the XSD where provided to me by whatever
protocol I was implementing. The service provider would rewrite their
XSD completely (to use substitution groups or whatever) and even
though the resulting XML structure would remain basically the same,
the classes generated by xjc would be completely different forcing me
to rewrite a bunch of my code. And I gave up on supporting several
versions of the XSD at the same time.

But this time it is a bit different, I am in control of the XSD and I
use the JAXB annotations on my own POJOs directly, I do not use xjc
generated code. However you are right, it doesn't mean that at some
point I won't need to use converters to fix errors in my initial
design, and that will be a convenient solution.

>
> > Currently our JAXB annotations use the accessors. I wanted to do the same
> > in XStream in case some of the accessors have some extra logic in it and
> > also to make the benchmark as fair as possible.
> >
> > I will review our accessors and if none of them do anything special, I
> > guess accessing the fields directly is not a big issue.
>
> One general advice: Instantiating an XStream instance and setting it up is a
> very expensive operation. Therefore you should do this only once and then
> reuse the prepared instance every time. You may use this instance even
> concurrently since marshalling/unmarshalling is threadsafe.
>
Yes I have learned that from JAXB too which has a costly JAXBContext.
I do use a static final XStream object.
>
> If you have to optimize extremely for speed, you should create custom
> converters for your objects instead of using the default ones based on
> reflection. This will have a similar effect compared to the JAXB stubs.
>
Thanks I'll keep that in mind.

>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email