RE: Minor changes to bean serializer -- request a review by a com mitter

["Nelson, Christopher" <cn...@synchrony.net>]

This is a pretty good point.  The only downside is that you may have things
silently fail that should throw errors.  You could have an xml request bound
to the wrong bean, and with lenient bean serializer it will instantiate the
bean but not set any properties, whereas before it would throw
IllegalArgumentException.  I do agree you want to offer both behaviors
though.  The reason I wanted it this way is much as you describe: I want
additions to the xml (or additions to the java bean being serialized) not to
cause someone using an older version to puke.  For us we don't want to push
changes to our customers sending us SOAP requests unless absolutely
necessary.  As far as which is default, I certainly have no objections to
making lenient bean serializer the default, but in that case you would also
want a "restrictive" bean serializer I would think -- but would anyone ever
bother to use it?  It would be nicer still to have a restrictive property
that could be set on BeanSerializer, but alas there would be nowhere to set
it since the framework takes care of instantiating the serializer for you.
Hmmm... well at the very least, the getWriteProperty method should
definitely be protected so people can easily subclass -- and since we have
both behaviors, it would be nice to keep both available.

My .02

-----Original Message-----
From: Kevin Mitchell [mailto:kevin.mitchell@xmls.com]
Sent: Thursday, October 05, 2000 8:38 AM
To: 'soap-dev@xml.apache.org '
Subject: RE: Minor changes to bean serializer -- request a review by a
com mitter


Actually, I think it does make sense for the behavior exhibited by the
LenientBeanSerializer to be the default. One of the advantages of XML as a
data exchange mechanism is the ability for one party to add information
without affecting the other(s); one just ignores the information it doesn't
care about. I think the default should be less restrictive (simple), and
folks can implement customizations to make things more restrictive.

others??


-----Original Message-----
From: Nelson, Christopher
To: soap-dev@xml.apache.org
Cc: Galluzzo, Eric
Sent: 10/4/2000 5:24 PM
Subject: Minor changes to bean serializer -- request a review by a committ
er

We needed to make a few minor changes to BeanSerializer to make it do
something useful for our project.  We needed to have a version that
would be
less sensitive to change -- a lenient bean serializer if you will.  The
current bean serializer will not have a problem if a property is added
that
is unknown, but will die if a property that it finds in the XML is not
present on the bean.  We wanted to change this slightly so that it will
ignore properties in the XML that it cannot match with properties on the
actual bean in unmarshall().  It would probably not make sense to have
this
be the default logic, so we created a LenientBeanSerializer that extends
BeanSerializer.  But in order to do this, we had to change the
getWriteMethod() method from private to protected so we could override
it.
We also took the liberty of removing the static keyword from several
methods
that seemed to no longer require it.  We would request one of the
authorized
submitters to have a look at our changes and if there are no serious
objections, to submit the code to CVS.

I've attached our version of BeanSerializer, a diff with the one in CVS,
and
LenientBeanSerializer.  BeanSerializer is mainly what we would like to
see
reach CVS. LenientBeanSerializer is provided for informational purposes,
but
if other folks find it interesting, great.

Thanks very much,

Chris Nelson
Eric Galluzzo
Synchrony Communications, Inc.

 <<BeanSerializer.java>>  <<BeanSerializer.java.orig>>  
<<BeanSerializer.patch>>  <<LenientBeanSerializer.java>> 

Re: Minor changes to bean serializer -- request a review by a committer

[Dave Schaumann <ds...@rdc.vanteon.com>]

"Nelson, Christopher" wrote:
> 
> This is a pretty good point.  The only downside is that you may
> have things silently fail that should throw errors.  You could
> have an xml request bound to the wrong bean, and with lenient 
> bean serializer it will instantiate the bean but not set any 
> properties, whereas before it would throw IllegalArgumentException.  
> I do agree you want to offer both behaviors though.

Isn't this what the mustUnderstand attribute is for, or is it
strictly for controlling the processing phase (as opposed to
(un)serialization)?

Perhaps a "decoderMustUnderstand" attribute is needed?

<snip>

-Dave

Re: Minor changes to bean serializer -- request a review by a committer

[Dave Schaumann <ds...@rdc.vanteon.com>]

"Nelson, Christopher" wrote:
> 
> This is a pretty good point.  The only downside is that you may
> have things silently fail that should throw errors.  You could
> have an xml request bound to the wrong bean, and with lenient 
> bean serializer it will instantiate the bean but not set any 
> properties, whereas before it would throw IllegalArgumentException.  
> I do agree you want to offer both behaviors though.

Isn't this what the mustUnderstand attribute is for, or is it
strictly for controlling the processing phase (as opposed to
(un)serialization)?

Perhaps a "decoderMustUnderstand" attribute is needed?

<snip>

-Dave