Venkat, See from the point of view of someone using Axis. they would be confused if they get a java.util.sql.Date. can't hack the code just to get roundtrip working. I will look more.
-- dims On 6/26/05, Venkat Reddy <[EMAIL PROTECTED]> wrote: > 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 > > > > > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
