CODEWITHSUNDEEP
gwtserialization
Stroboskop
Stroboskop

Reputation: 4356

GWT java.util.Date serialization with CustomFieldSerializer fails in debugger

I had a problem with the way Date was serialized by GWT 2.4.0 and the easiest solution seemed to be to write a Date_CustomFieldSerializer - overloading the original implementation.

But depending on how i start the application i get different results. Gladly the deployed version seems to work without any trouble. Starting a debugging session from Eclipse on the other hand leads to this message:

com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: The response could not be deserialized
    at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.onResponseReceived(RequestCallbackAdapter.java:221)
    at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:287)
    at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:395)
    ...
Caused by: com.google.gwt.user.client.rpc.SerializationException: java.util.Date/1659716317
    at com.google.gwt.user.client.rpc.impl.SerializerBase.getTypeHandler(SerializerBase.java:153)

I debugged both the server and the client side and the server is using my serializer and the client side fails when it's looking up the serializer by its "type signature": java.util.Date/1659716317

Oddly the client has a map containing a serializer for java.util.Date/965047388.

How does GWT create these type signatures and how can they be different when i am using the GWT debugger?

-- edit --

I now know how the numbers are generated. GWT calculates a CRC32 hash of the class names in the hierachy (and sometimes the methods as well).

java.util.Date
com.google.gwt.user.client.rpc.core.java.util.Date_CustomFieldSerializer
java.lang.Object
--> 1659716317 (server side)

java.util.Date
java.lang.Object
--> 965047388 (client side)

I just can't find the spot when the GWT calculates the hashes for the client side to see why it doesn't know the serializer, because it's somewhere between a CompilingClassLoader and runtime generated classes.

Upvotes: 0

Views: 994

Answers (2)

Koen
Koen

Reputation: 11

For anyone who is having this same problem, I had the error message for a few days now, yesterday I found the cause!

I had 2 versions of different versions of the class Date_CustomFieldSerializer on my classpath. The wrong one was added in my classpath because it was in the gwt-servlet-2.2.0.jar that was a dependency of the google gin 1.5 library which I use in my project.

I upgraded the google gin in my project to version 2.1.2 with doesn't have a gwt-servlet dependency to. This way no different versions of the Date_CustomFieldSerializer class should be in the classpath. If you have the same cause and you don't want to upgrade your google gin, you can simply exclude the dependency gwt-servlet-2.2.0 from the google gin 1.5 dependency in your pom. Like this:

<dependencies>
  <dependency>
    <groupId>sample.ProjectA</groupId>
    <artifactId>Project-A</artifactId>
    <version>1.0</version>
    <scope>compile</scope>
    <exclusions>
      <exclusion>  <!-- declare the exclusion here -->
        <groupId>sample.ProjectB</groupId>
        <artifactId>Project-B</artifactId>
      </exclusion>
    </exclusions> 
  </dependency>
</dependencies>

Upvotes: 1

Stroboskop
Stroboskop

Reputation: 4356

The reason the client side didn't have the serializer was simply that GWT couldn't compile it to JavaScript (because of some server side logging references that were added by accident).

Unless you use "strict" compilation rules, these JavaScript compiles fail silently (or add a single line to the compiler output that gets drowned in other messages) and you won't know what you're missing until you need it.

Upvotes: 0

Related Questions