Web services serialization and deserialization troubleshooting tips

Time zone information in deserialized java.util.Calendar is not as expected

When the client and server are based on Java code and a java.util.Calendar instance is received, the time zone in the received java.util.Calendar instance might be different from that of the java.util.Calendar instance that was sent.

This difference occurs because the java.util.Calendar is encoded as an xsd:dateTime for transmission. An xsd:dateTime is required to encode the correct time (base time plus or minus a time zone offset), but is not required to preserve locale information, including the original time zone.

The fact that the time zone for the current locale is not preserved needs to be accounted for when comparing Calendar instances. The java.util.Calendar class equals method checks that the time zones are the same when determining equality. Because the time zone in a deserialized Calendar instance might not match the current locale, use the before and after comparison methods to test that two Calendars refer to the same date and time as shown in the following examples:

java.util.Calendar c1 = ...// Date and time in time zone 1
java.util.Calendar c2 = ...// Same date and equivalent time, but in time zone 2

// c1 and c2 are not equal because their time zones are different
if (c1.equals (c2)) System.out.println("c1 and c2 are equal");

// but c1 and c2 do compare as "not before and not after" since they represent 
the same date and time
if (!c1.after(c2) & !c1.before(c2) {
			System.out.println("c1 and c2 are equivalent");
}

Mixing web services client and server bindings causes errors

Web Services for Java Platform, Enterprise Edition (Java EE) and the Java API for XML-based remote procedure call (JAX-RPC) specifications do not support round-trip mapping between Java code and a Web Services Description Language (WSDL) document for all Java types. For example, we cannot turn or serialize a Java Date into XML code and then turn it back or deserialize it into a Java Date. This action deserializes as Java Calendar.

If we have a Java implementation that we create a WSDL document from, and we generate client bindings from the WSDL document, the client classes can be different from the server classes even though the client classes have the same package and class names. The web service client classes must be kept separate from the web service server classes. For example, do not place the web service server bindings classes in a utility Java archive (JAR) file and then include a web service client JAR file that references the same utility JAR file.

If we do not keep the web services client and server classes separate, a variety of exceptions can occur, depending on the Java classes used. The following is a sample stack trace error that can occur:

com.ibm.ws.webservices.engine.PivotHandlerWrapper TRAS0014I: The following exception was 
loggedjava.lang.NoSuchMethodError: com.ibm.wssvt.acme.websvcs.ExtWSPolicyData:
   method getStartDate()Ljava/util/Date; 
not found 
at com.ibm.wssvt.acme.websvcs.ExtWSPolicyData_Ser.addElements(ExtWSPolicyData_Ser.java: 210)
at com.ibm.wssvt.acme.websvcs.ExtWSPolicyData_Ser.serialize (ExtWSPolicyData_Swer.java:29)
at com.ibm.ws.webservices.engine.encoding.SerializationContextImpl.serializeActual 
(SerializationContextImpl.java 719)
at com.ibm.ws.webservices.engine.encoding.SerializationContextImpl.serialize 
(SerializationContextImpl.java: 463)

The problem is caused using an interface as shown in the following example for the service endpoint interface in the service implementation:

package server:
public interface Test_SEI extends java.rmi.Remote {
	public java.util.Calendar getCalendar () throws java.rmi.RemoteException;
	public java.util.Date getDate() throws java.rmi.RemoteException;
}

When this interface is compiled and run through the Java2WSDL command-line tool, the WSDL document maps the methods as shown in the following example:

<wsdl:message name="getDateResponse">
	<wsdl:part name="getDateReturn" type="xsd:dateTime"/>
</wsdl:message>

<wsdl:message name="getCalendarResponse">
	<wsdl:part name="getCalendarReturn" type="xsd:dateTime"/>
</wsdl:message>

The JAX-RPC mapping implemented by the Java2WSDL tool has mapped both the java.util.Date and java.util.Calendar instances to the xsd:dateTime XML type . The next step is to use the generated WSDL file to create a client for the web service. When we run the WSDL2Java tool on the generated WSDL, the generated classes include a different version of the server.Test_SEI interface, for example:

package server;
public interface Test_SEI extends java.rmi.Remote {
	public java.util.Calendar getCalendar() throws java.rmi.RemoteException;
	public java.util.Calendar getDate() throws java.rmi.RemoteException;
}

The client version of the service.Test_SEI interface is different from the server version in that both the getCalendar and getDate methods return java.util.Calendar. The serialization and deserialization code that the client expects is the client version of the service endpoint interface. If the server version inadvertently is contained in the client CLASSPATH variable, at either compilation or run time, an error occurs.

In addition to the NoSuchMethod error, the IncompatibleClassChangeError and ClassCastException can occur. However, almost any runtime exception can occur. The best practice is to be diligent about separating client web services bindings classes from server web services bindings classes. Always place the client bindings classes and server bindings classes in separate modules. If theses binding classes are in the same application, place the bindings classes in utility JAR files that are not shared between modules.

Troubleshoot web services

Web services specifications and APIs

WSDL2Java command for JAX-RPC applications

Java2WSDL command for JAX-RPC applications