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

Morganne

Answer 1

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

Bolan

Wow, not the best exception message for that imho !? I've been debugging the code, and could see my class wasn't making it to the whitelist but not why - so simple! – Rockweed

What Kerem said is definitely key. Another issue we've run into is that you shouldn't try to serialize inner classes. All classes being serialized should be separate classes by themselves. – Beecher

@Bolan Link does not exists any more http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize. – Inmate

Answer 2

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)

Uniaxial

Yep, after a clean rebuild I started to see this error. After reviewing the code and verifying that all the RPC classes were serializable, I cleared the browser cache and everything worked. – Poncho

Answer 3

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.

Cutis

I can confim this issue. Had to translate all java.io.Serializable to GWT isSerializable to be able to host an application on a Linux machine instead of Windows. With isSerializable any OS will do. It seems that not all permutations are built correctly. – Luffa

Not only on linux, its happens on windows when using glassfish – Sheathing

I confirm this fix solved my problem. When connecting directly to my website it was already working but embed in an iPhone or Android app the web service get this error. By using IsSerializable it fix the problem – Sech

@Luffa Does GWT isSerializable will solve this issue irrespective of OS and Application/Web servers instead of java.io.Serializable. – Churchy

Answer 4

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?

Nieman

This was what was actually happening in my case ... I compiled the server side application completely without GWT and wanted to do that in a separate step. I had to restart the application server after compiling the GWT part and after that everything worked fine :-) Thanks for the tip. – Clanton

Answer 5

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

Lauretta

Answer 6

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.

Combined

Just encounters same issue. All was good, public class implemented Serializable except a new embedded private class which did not implement Serializable. – Padget

Answer 7

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.

Congelation

Answer 8

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?

Sandstone

Answer 9

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

Fa

on my project, I managed to solve it by removing folder gwt-unitCache as well. – Tortious

technically this happens because of what @Uniaxial said. – Blearyeyed

Answer 10

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.

Protean

Answer 11

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.

Mulder

Answer 12

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.

Koziarz

Answer 13

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.

Cheap