Deserialization of xsi:nil elements in BeanDeserializer

[Thomas Sandholm <sa...@mcs.anl.gov>]

I believe there is a problem in the newest 
BeanDeserializer/DeserializationContextImpl code(checked out yesterday). 
When I send in an element marked with xsi:nil="true" the QName passed in to 
the getDeserializerForType method is null, and hence the log.error message 
doing a toString on the QName will result in a null pointer exception. If I 
add in a check whether the qname passed in is null it all works fine. 
Alternatively the BeanSerializer could avoid calling the 
getDesrializerForType if its context.getTypeFromAttributes(namespace, 
localName, attributes) returns a null QName, or it could explicitly check 
for the xsi:nil attribute.

/Thomas

Re: Deserialization of xsi:nil elements in BeanDeserializer

[Thomas Sandholm <sa...@mcs.anl.gov>]

Digging a bit deeper into this, it actually turned out to be a 
configuration problem causing this behavior. But maybe it wouldn't hurt to 
put in the null checks in the code anyhow.
/Thomas
At 01:35 PM 3/14/2002 -0600, Thomas Sandholm wrote:
>I believe there is a problem in the newest 
>BeanDeserializer/DeserializationContextImpl code(checked out yesterday). 
>When I send in an element marked with xsi:nil="true" the QName passed in 
>to the getDeserializerForType method is null, and hence the log.error 
>message doing a toString on the QName will result in a null pointer 
>exception. If I add in a check whether the qname passed in is null it all 
>works fine. Alternatively the BeanSerializer could avoid calling the 
>getDesrializerForType if its context.getTypeFromAttributes(namespace, 
>localName, attributes) returns a null QName, or it could explicitly check 
>for the xsi:nil attribute.
>
>/Thomas