BeanSerializer

[Kevin Mitchell <ke...@xmls.com>]

I noticed that BeanSerializer's marshall method determines the class of the
value to be serialized from the PropertyDescriptor, not from the actual
object returned from the property read method.  When the read method
signature specifies a base class, but method returns a subclass, a
serializer bound to the subclass will not get picked up.  Perhaps an example
will illustrate best:

<example>
public class A {

	public B getB() {return new C();}
}

public abstract class B {}

public final class C extends B {};

public final class D extends B {};
</example>

There is no way for a serializer for C to be invoked, b/c BeanSerializer
will base the serilialzer lookup on B, not C.

A simple fix for this will be to use the class of the object returned from
the bean's property read method, assuming the object is not null. If the
object is null, use the class from the property descriptor.

If there is consensus, I will commit the change. Comments??

Re: BeanSerializer

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

Is that valid w.r.t. the bean spec?? I thought that the type of
a property must be gotten from its descriptor and not by looking
at the return value of the method. We need to keep the bean
serializer to follow whatever the bean spec says is the right
way to do it.

Sanjiva.

----- Original Message -----
From: "Kevin Mitchell" <ke...@xmls.com>
To: <so...@xml.apache.org>
Sent: Monday, September 18, 2000 5:42 PM
Subject: BeanSerializer


> I noticed that BeanSerializer's marshall method determines the class of the
> value to be serialized from the PropertyDescriptor, not from the actual
> object returned from the property read method.  When the read method
> signature specifies a base class, but method returns a subclass, a
> serializer bound to the subclass will not get picked up.  Perhaps an example
> will illustrate best:
>
> <example>
> public class A {
>
> public B getB() {return new C();}
> }
>
> public abstract class B {}
>
> public final class C extends B {};
>
> public final class D extends B {};
> </example>
>
> There is no way for a serializer for C to be invoked, b/c BeanSerializer
> will base the serilialzer lookup on B, not C.
>
> A simple fix for this will be to use the class of the object returned from
> the bean's property read method, assuming the object is not null. If the
> object is null, use the class from the property descriptor.
>
> If there is consensus, I will commit the change. Comments??

Re: BeanSerializer

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

Is that valid w.r.t. the bean spec?? I thought that the type of
a property must be gotten from its descriptor and not by looking
at the return value of the method. We need to keep the bean
serializer to follow whatever the bean spec says is the right
way to do it.

Sanjiva.

----- Original Message -----
From: "Kevin Mitchell" <ke...@xmls.com>
To: <so...@xml.apache.org>
Sent: Monday, September 18, 2000 5:42 PM
Subject: BeanSerializer


> I noticed that BeanSerializer's marshall method determines the class of the
> value to be serialized from the PropertyDescriptor, not from the actual
> object returned from the property read method.  When the read method
> signature specifies a base class, but method returns a subclass, a
> serializer bound to the subclass will not get picked up.  Perhaps an example
> will illustrate best:
>
> <example>
> public class A {
>
> public B getB() {return new C();}
> }
>
> public abstract class B {}
>
> public final class C extends B {};
>
> public final class D extends B {};
> </example>
>
> There is no way for a serializer for C to be invoked, b/c BeanSerializer
> will base the serilialzer lookup on B, not C.
>
> A simple fix for this will be to use the class of the object returned from
> the bean's property read method, assuming the object is not null. If the
> object is null, use the class from the property descriptor.
>
> If there is consensus, I will commit the change. Comments??