DO NOT REPLY [Bug 22999] - xs:date not serialized/deserialized correctly

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22999>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22999

xs:date not serialized/deserialized correctly





------- Additional Comments From kbrichan@comcast.net  2003-10-03 20:03 -------
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 correctly 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.