GWT - occasional com.google.gwt.user.client.rpc.SerializationException

Question

we are haunted by occasional occurences of exceptions such as:

com.google.gwt.user.client.rpc.SerializationException: Type 'xxx' was not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.For security purposes, this type will not be serialized.: instance = xxx at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:610) at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject(AbstractSerializationStreamWriter.java:129) at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter$ValueWriter$8.write(ServerSerializationStreamWriter.java:152) at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue(ServerSerializationStreamWriter.java:534) at com.google.gwt.user.server.rpc.RPC.encodeResponse(RPC.java:609) at com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess(RPC.java:467) at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:564) at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188) at de.softconex.travicemanager.server.TraviceManagerServiceImpl.processCall(TraviceManagerServiceImpl.java:615) at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224) at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508) at java.lang.Thread.run(Thread.java:619)

The application is normally running fine. The indicated class implements Serializable (the whole object graph).

So far the only patterns / observations are:

• we seem to have the issue only when the application is used inside an iframe

• the problem seems to happen when a new version of the application has been deployed

• running firefox in privacy mode (disabling all caches etc.) doesn't fix the problem

Any ideas?

Holger

Answer 1

I had this problem when running SuperDevelopmentMode with a setup where codeserver was not on the same host as tomcat server. I had codeserver on my host, while tomcat running in the docker container. It turns out in such setup app server cannot get the right serialization policy files, so quite similar as described by thomaux in one of answers above, just different setup.

I had to add -Dgwt.codeserver.port=9876 to start parameters of tomcat as described here. This causes GWT SuperDevMode to switch to mode of getting serialization policy files through network. Still the url is hardcoded in com.google.gwt.user.server.rpc.RemoteServiceServlet#getCodeServerPolicyUrl as

"http://localhost:" + codeServerPort 

so you have to make sure that your tomcat can reach codeserver on that port, by tunneling or routing the traffic if necessary. Alternative is to hack GWT code to allow changing that localhost to something else too, but this doesn't look clean and secure.

Answer 2

First make sure you have a 'clean' serializable class ie empty constructor, no inner classes implementing serializable and use GWT Serializable class instead of Java Serializable class. Then simply open your site in an Incognito tab (Chrome) solves the problem. Local browser cache causes loading old rpc files.

Answer 3

The best way to know the exact issue is to compile your code using -logLevel DEBUG or TRACE and check inside Validating Units. I am sure you would be able to find out the exact issue with line numbers as well.

Answer 4

Very possible reason - older version of client is still cached in browser. It sends rpc requests, but server is already restarted and have newer versions of rpc files (*.symbolMap)

Answer 5

I had the same problem and I found a solution from another person:

"There is a possibility that you have a class which implements Serializable and you have an attribute field within that class which is not Serializable hence you might be getting this exception."

Many thanks to that person :)

My advice is to make all fields (which are not primitive types) in your class to implement Serializable also! This solved my problem.

Answer 6

This problem occurs when a GWT 2.5 application is compiled using JDK 1.7. GWT 2.5 supports JDK 1.6 and using this version of JDK will fix this issue.

Answer 7

I encountered the problem when I used Tomcat6 + Devmode in Ubuntu Lucid amd64. Using com.google.gwt.user.client.rpc.IsSerializable instead of java.io.Serializable seemed solved the problem.

Answer 8

I assume you're running the application on localhost and in hosted mode? If so, you might want to keep an eye on the work directory (or the equivalent directory if you're not running the application in a tomcat server). Check the webapp's folder for serialization policiy files (*.gwt.rpc).

It's possible they're not loaded correctly, the only workaround we have found so far, is to restart your server after each serialization fault.

The problem is due to the fact GWT will generate its serialization policy files at run time, assuming you're running in hosted mode. In compiled mode, GWT will generate all necessary files at compile time. AFAIK, tomcat's unable to load in the resource files at run time and hence will not include the serialization files each time they are needed for the first time.

When restarting the server, tomcat's able to pick up the previously generated file and hence you shouldn't receive the same error after restarting.

Can you verify this?

Answer 9

I've had the same error and fix this by clean the browse cache and navigation history.

Answer 10

So the RPC files are unique because they are loaded by servlets as well as being used in GWT. See http://code.google.com/webtoolkit/release-notes.html#Release_Notes_1_4_59 where it says "This file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource()"

Is it possible the new application is being reloaded dynamically and getResource is failing in some way? Does restarting the application fix things?

Answer 11

If you are running on JBoss, this might be due to the fact that the previously deployed application is not deleted when undeployed. To fix this, you must modify the following file in JBoss: ${JBOSS_HOME}/server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml and set the following attribute to true: deleteWorkDirOnContextDestroy

When the previously deployed application is not cleaned up, GWT can be confused about which RPC file it needs to load and you end up with those SerializationException

Answer 12

I was getting a SerializationException also but I was also seeing this error showing up right before the serialization exception:

[uptimereports/2.340102563369350884].: Example : error : cannot find template registration-confirmation.vm

It turned out to be a problem finding my velocity template. Once I fixed that problem the SerializationException stopped showing up, so if you follow Kerem's advice and still have problems, look for other exceptions in your log.

Answer 13

did you check http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize the article says: It has a default (zero argument) constructor with any access modifier (e.g. private Foo(){} will work)

I'm allways forgetting zeroargument const. when I am making a serializable object :D