Troubleshoot serialization and deserialization in Web services

This topic discusses problems that one can have when you perform serialization and deserialization in Web services.

Each section in this topic is a problem that you might experience while serializing and deserializing Web services. A solution is provided to help you troubleshoot the problem.

 

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 2 Platform, Enterprise Edition (J2EE) and the Java API for XML-based remote procedure call (JAX-RPC) do not support round-trip mapping between Java code and a Web Services Description Language (WSDL) document for all Java types. For example, one cannot turn (serialize) a Java Date into XML code and then turn it back (deserialize) into a Java Date. This action deserializes as Java Calendar.

If you have a Java implementation that you create a WSDL document from, and you 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 JAR file and then include a Web service client JAR file that references the same utility JAR file.

If you 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 by 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 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 you run the WSDL2Java command-line 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.Date getDate() throws java.rmi.RemoteException;
}

Note: 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 appears in the client CLASSPATH variable, at either compilation or run time, an error occurs.

In addition to theNoSuchMethod error, the IncompatibleClassChangeError and ClassCastException can occur. However, almost any run-time 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.

---

 

Related Tasks

Troubleshooting Web services

 

---