[jira] Commented: (AXIS-1456) Mapping of service interfaces defined using java.sql.Date to xsd:date does not work

["vishal (JIRA)" <ax...@ws.apache.org>]

     [ http://issues.apache.org/jira/browse/AXIS-1456?page=comments#action_61365 ]
     
vishal commented on AXIS-1456:
------------------------------

Hi Guys..

I got the patch suggested by "Niall Smartin" and applied to Axis 1-1 and Axis1-2 RC3, but it complies fine with later only though there are deprecated warnings for other stuff (not woried about that as it builds fine)). But that patch hasn't worked at all.
I still get the Axis fault on my server side when sql.Date is passed 
from the client side to server side. I'm wondering if yr solution has really worked. The status seems to be open as well.
Can anyone else please reflect some insight on this.

Vishal.

> 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: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.1
>  Environment: Multiple environments (i.e. UNIX and Windows based)
>     Reporter: Alan Murphy
>     Assignee: Davanum Srinivas
>  Attachments: DateDeserializer.java.patch
>
> 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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira