On 2/16/07, Johnson, Larry D (LJOHNSON) <[EMAIL PROTECTED]> wrote:
I did not specify what platform we are using. We are currently using Axis2 v1.1, Java v1.5 and Tomcat 5.5.20. I have also run a similar test using the .NET framework. The client receives a DateTime object from the stubs. On .NET, the value returned to the client is correct for the current timezone. This appears to be an issue in the generated Java stub classes. Also, I saw one additional oddity. As reported below, the WSDL generated element for the java.util.Date element is as follows: <xs:element name="departureTime" type="xs:dateTime"/> Even though I have not specified that this should be a required field, it does not have an attribute of nillable="true"; however the SOAP message being returned to the client has the form: <departureTime xmlns:nil="http://www.w3.org/2001/XMLSchema-instance"; nil:nil="true" /> The nillable attribute is set true here. On the client side, the following exception is received: *java.lang.RuntimeException*: *java.lang.NumberFormatException* at com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub.fromOM(Unknown Source) at com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub.processLocateBooking(Unknown Source) at com.arinc.afd.jal.webapp.CLFTestClient.jlLocateBooking(* CLFTestClient.java:101*) at com.arinc.afd.jal.webapp.CLFTestClient.main(*CLFTestClient.java :315*) Caused by: *java.lang.NumberFormatException* at org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime(* ConverterUtil.java:499*) at com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub$Flight$Factory.parse(Unknown Source) Any thoughts?
ADB supports nillable attribute . can you please send your wsdl (set the nillable true) and the soap request you got from the .NET server? Regards,
Larry Johnson ------------------------------ *From:* Johnson, Larry D (LJOHNSON) [mailto:[EMAIL PROTECTED] *Sent:* Thursday, February 15, 2007 11:59 AM *To:* [email protected] *Subject:* TimeZone Not Handled Properly In java.util.Date Conversions It seems the conversions of the java.util.Date class are not being handled properly. I have defined a server return value of a java.util.Date. The WSDL automatically generated for that value is as follows: <xs:element name="departureTime" type="xs:dateTime"/> The client stub is generated using the provided WSDL2Java. The client stub returns a java.util.Calendar object for this value. So far all is well. The problem comes in when you start looking into the handling of the TimeZone from server to client. Lets say both client and server are within the "Central Standard Time" zone. When the server provides the Date object to the POJO interface, the time is "1970-01-01T23:55:00.000". Axis2 then converts that time to a GMT time. The SOAP message contains "1970-01-02T05:55:00.000Z". Again all is well. When the client gets the Calendar object from the stub classes, the value is: 01/02/1970 11:55:00 Greenwich Mean Time. The time value is incorrect for the TimeZone indicate; however, it is correct for the local TimeZone. The client simply performs the following: responeData.getDepartureTime(); Am I missing something here? Should the returned Calendar either keep the time consistent with GMT or convert the time to local time while changing the TimeZone to indicate the local TimeZone? Regards, Larry Johnson
-- Amila Suriarachchi, WSO2 Inc.
