The stuff Tom just put into CVS works for me (returning null deserializer if qname is null). /Thomas At 10:23 AM 3/15/2002 -0600, R J Scheuerle Jr wrote: >Could you send the patch that you want to incorporate. > >Thanks > >Rich Scheuerle >XML & Web Services Development >512-838-5115 (IBM TL 678-5115) > > > > > Thomas > Sandholm > > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > .gov> cc: > > Subject: Re: > Deserialization of xsi:nil elements in BeanDeserializer > 03/14/2002 > 02:04 > > PM > > Please respond > to > > axis-dev > > > > > > > > >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
Thomas Sandholm <[EMAIL PROTECTED]> The Globus Project(tm) <http://www.globus.org> Ph: 630-252-1682, Fax: 630-252-1997 Argonne National Laboratory
