axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From axis-...@ws.apache.org
Subject [jira] Updated: (AXIS-1456) Mapping of service interfaces defined using java.sql.Date to xsd:date does not work
Date Thu, 29 Jul 2004 10:58:40 GMT
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


Mime
View raw message