Well, it does map to java.util.Calendar as required by JAX-RPC when the typemapping flag is appropriately specified. But without the type mapping switch, may be it can default to java.util.sql.Date. Otherwise, is there a way we can make the roundtrip test case work (which i submitted)?.
- venkat On 6/26/05, Davanum Srinivas (JIRA) <[email protected]> wrote: > [ > http://issues.apache.org/jira/browse/AXIS-1456?page=comments#action_12314505 ] > > Davanum Srinivas commented on AXIS-1456: > ---------------------------------------- > > that's against JAXRPC spec > > -- dims > > > Mapping of service interfaces defined using java.sql.Date to xsd:date does > > not work > > ----------------------------------------------------------------------------------- > > > > Key: AXIS-1456 > > URL: http://issues.apache.org/jira/browse/AXIS-1456 > > Project: Apache Axis > > Type: Bug > > Components: Serialization/Deserialization > > Versions: 1.1 > > Environment: Multiple environments (i.e. UNIX and Windows based) > > Reporter: Alan Murphy > > Assignee: Venkat Reddy > > Attachments: DateDeserializer.java.patch, sqldate-testcase.zip > > > > Whilst JAX-RPC does not define a standard mapping from a Java class to > > xsd:date, Apache Axis has a non standard extension which maps service > > interfaces defined using java.sql.Date to xsd:date. Unfortunately this does > > not work out-of-the-box. When a parameter of type xsd:date is sent from a > > client stub to an AXIS server, it is erroneously deserialized as a > > java.util.Date. This is despite the fact that both the WSDD, and XML > > request, specify that the parameter is of type XSD:Date, rather than > > XSD:DateTime. > > The resultant effect of this incorrect deserialization, is that AXIS will > > erroneously try to find a method to invoke with a java.util.Date in it's > > signature, rather than a java.sql.Date (which the method signature actually > > specifies), and hence will throw a 'no such method error'. > > The problem is resolved by implementing a custom deserializer which, when > > registered against the type java.sql.Date, merely converts the incorrectly > > deserialized java.util.Date to a java.sql.Date, allowing AXIS to invoke the > > correct method. > > The code for the overriden makeValue function of the custom deserializer is > > as follows: > > public Object makeValue(String source) { > > > > Object obj = super.makeValue(source); > > > > if (javaType == java.sql.Date.class) { > > if (obj instanceof java.sql.Date) { > > return obj; > > } else if (obj instanceof java.util.Date) { > > return new > > java.sql.Date(((java.util.Date)obj).getTime()); > > } > > } > > > > if (javaType == java.util.Date.class) { > > if (obj instanceof java.util.Date) { > > return obj; > > } > > } > > > > throw new RuntimeException( > > "cannot convert " + obj.getClass().getName() + " to " + > > javaType.getName() > > ); > > } > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > >
