Web services serialization and deserialization troubleshooting tips
Use these tips to troubleshoot problems that you 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.
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, you 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 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 Java archive (JAR) file and then include a web service client JAR file that references the same utility JAR file.
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 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 you
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.