axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (AXIS-1456) Mapping of service interfaces defined using java.sql.Date to xsd:date does not work
Date Thu, 29 Jul 2004 10:56:40 GMT
The following comment has been added to this issue:

     Author: Niall Smart
    Created: Thu, 29 Jul 2004 3:56 AM

The problem here is fairly simple, DateDeserializer is registered as a deserializer for java.util.Date,
java.util.Calendar and java.sql.Date in the default type registry, but it doesn't properly
handle the java.sql.Date case.

I am attaching a simple patch which constructs the appropriate type after checking "this.javaType"
(which is the type required from the deserializer).

I haven't been able to run the regression tests on my machine due to the vagaries (ahem) of
the existing build system, but the patch is quite similar to the one we have applied locally
to Axis 1.1.

It also addresses a second issue which I noticed when fixing this bug -- the existing test
on "this.javaType" was only applied for BC dates.

View this comment:

View the issue:

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
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis

   Reporter: Alan Murphy

    Created: Thu, 15 Jul 2004 3:56 AM
    Updated: Thu, 29 Jul 2004 3:56 AM
Environment: Multiple environments (i.e. UNIX and Windows based)

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:

If you want more information on JIRA, or have a bug to report see:

View raw message