Nah, I wouldn't bother to throw an error, just return null and the rest of the deserialization mechanism will deal.
--G > -----Original Message----- > From: Tom Jordahl [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 14, 2002 4:39 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Deserialization of xsi:nil elements in BeanDeserializer > > > > Thomas, > > Do have a suggested patch for this? > > Here is what I was thinking of doing, anyone have a > preference for how the error message should look? > > log.error(JavaUtils.getMessage( > "noFactory00", xmlType ? xmlType.toString() : "''")); > > Message is: > noFactory00=!! No Factory for {0} > > -- > Tom Jordahl > Macromedia > > > -----Original Message----- > From: Thomas Sandholm [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 14, 2002 3:04 PM > To: [EMAIL PROTECTED] > Subject: Re: Deserialization of xsi:nil elements in BeanDeserializer > > > 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 >
