Hi Larry,
You're correct on your assumptions, that if a Calendar is being returned
it should have a consistent time value and time zone. In this case the
time zone of the Calendar should be set to UTC. That said, there are
some seriously warped issues involved - Calendar *always* works with
time zones, while xsd:dateTimes either use UTC times or times with no
zone information (where the latter have basically a half-day uncertainty
factor). xsd:dateTimes do not support time zones in the Java sense at all.
The inappropriate use of Calendar for XML dateTime values in Java is a
long-standing issue that goes back to JAX-RPC days. Calendar just
doesn't work for dateTimes, which is why recent versions of Java have an
added javax.xml.datatype.XMLGregorianCalendar class. Ironically, the
java.util.Date class *is* a direct representation of standard dateTime
values, as long as you don't need sub-millisecond precision - but
because everyone got brainwashed into working with Calendar in Java
that's also what XML code generally uses.
The JiBX data binding support uses java.util.Date as the standard
xsd:dateTime representation, so one solution would be to switch to using
JiBX. I believe the JiBX linkage code generated by WSDL2Java also
handles the xsi:nillable issue properly, only generating this when
allowed by the schema and throwing an exception if a required value is null.
Aside from that, I suggest you enter bug reports in the Axis2 Jira on
these issues.
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Johnson, Larry D (LJOHNSON) 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?
Regards,
Larry Johnson
------------------------------------------------------------------------
*From:* Johnson, Larry D (LJOHNSON) [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, February 15, 2007 11:59 AM
*To:* axis-user@ws.apache.org
*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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
