problem with deserializing XSD_DATE

[Brook Richan <br...@sandlot.com>]

A NumberFormatException is thrown when deserializing attributes of type
XSD_DATE.

Background:
- XSD_DATE specification says the format is '2003-10-27'.
- XSD_DATETIME is '2003-10-27T15:75:06'.
- In other words, XSD_DATE does NOT have time and XSD_DATETIME MUST
have time. The two XSD types are not interchangable.
- org.apache.axis.encoding.ser.CalendarDeserializer throws if time is
NOT present.
- org.apache.axis.encoding.ser.DateDeserializer does not expect time to
be present.
- org.apache.axis.encoding.ser.BeanDeserializer is choosing
CalendarDeserializer for an XSD_DATE attribute, instead of
DateDeserializer.

Therefore, an exception is thrown by CalendarDeserializer when it
discovers the string has no "T" in it. What should have happened is
BeanDeserializer should have chosen DateDeserializer.

Cause:
- org.apache.axis.encoding.DefaultTypeMappingImpl correctly registers
the DateDeserializer for the combination of XSD_DATE and
java.util.Date.class
- org.apache.axis.schema.SchemaVersion2001 incorrectly registers the
CalendarDeserializer for the combination of XSD_DATETIME and
java.util.Date.class and correctly for the combination of XSD_DATETIME
and java.util.Calendar.class
- org.apache.axis.description.AttributeDesc correctly represents the
fact that the date attribute is of xml type XSD_DATE
- org.apache.axis.utils.BeanPropertyDescriptor correctly represents the
fact that the date attribute is of java type java.util.Date.class
- org.apache.axis.encoding.ser.BeanDeserializer.onStartChild has access
to BOTH the AttributeDesc and the BeanPropertyDescriptor, which,
together correctly represent that the attribute is of xml type XSD_DATE
and java type java.util.Date.class
- HOWEVER: onStartChild ignores the combination of XSD_DATE and
java.util.Date.class and simply asks what is the last registered XSD
type for java.util.Date.class, which happens to be XSD_DATETIME - - this
is irrelevant, and shouldn't be asked
- following it through, then, BeanDeserializer than asks for the
deserializer for the combination of java.util.Date.class and
XSD_DATETIME, which is the CalendarDeserializer

BeanDeserializer should be using the information it has in hand about
the COMBINATION of XSD_DATE and java.util.Date.class, instead of asking
what is the most recent XSD type registered for java.util.Date.class.

Workaround for now:

I can work around this in my program for now by waiting until all the
default type registrations have been done and then register again the
combination of XSD_DATE and java.util.Date.class. This causes XSD_DATE
now to be the last registered XML type for java.util.Date.class, which
causes BeanDeserializer to get the right DateDeserializer.

This is only a workaround. I shouldn't have to do this in every program
that accepts XSD_DATE attributes. BeanDeserializer should be fixed to be
aware of the COMBINATION of XML type and java type, not just the last
registered XML type for a given java type.

Brook Richan
New Client Software, Inc.
kbrichan@comcast.net