You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by ax...@ws.apache.org on 2004/07/29 12:58:40 UTC
[jira] Updated: (AXIS-1456) Mapping of service interfaces defined using java.sql.Date to xsd:date does not work
The following issue has been updated:
Updater: Niall Smart (mailto:niall@pobox.com)
Date: Thu, 29 Jul 2004 3:58 AM
Comment:
Patch against ws-axis_20040719043414 nightly.
Changes:
Attachment changed to DateDeserializer.java.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/AXIS-1456?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-1456
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-1456
Summary: Mapping of service interfaces defined using java.sql.Date to xsd:date does not work
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis
Components:
Serialization/Deserialization
Versions:
1.1
Assignee:
Reporter: Alan Murphy
Created: Thu, 15 Jul 2004 3:56 AM
Updated: Thu, 29 Jul 2004 3:58 AM
Environment: Multiple environments (i.e. UNIX and Windows based)
Description:
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()
);
}
---------------------------------------------------------------------
JIRA INFORMATION:
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