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.