Skip to content

InvocationException using GWT RPC and custom objects

If you are using GWT 1.4 and sending custom objects over the wire, and see an exception like this in your log files:


2007-11-09 11:06:13 Exception while dispatching incoming RPC call
com.google.gwt.user.client.rpc.SerializationException: Type 'com.foo.common.data.User' 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.
at com.google.gwt.user.server.rpc.impl.LegacySerializationPolicy.validateSerialize(LegacySerializationPolicy.java:136)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:331)
at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject(AbstractSerializationStreamWriter.java:81)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue(ServerSerializationStreamWriter.java:259)
at com.google.gwt.user.server.rpc.RPC.encodeResponse(RPC.java:574)
at com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess(RPC.java:442)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:530)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:265)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)

You may be very interested in this release note from the 1.4.59 release:

RPC now generates a serialization policy file during compilation. The serialization policy file contains a whitelist of allowed types which may be serialized. Its name is a strong hash name followed by .gwt.rpc. This file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource(). If it is not deployed properly, RPC will run in 1.3.3 compatibility mode and refuse to serialize types implementing Serializable. Updated 3/6/2011 to correct link location.

This exception caused me a world of grief, first because I wasn’t seeing anything in standard out (it logged to a different file), then because I couldn’t find the source of LegacySerializationPolicy, then because I have the gwt source in one directory, but because of rewrites, it appears to be served from another directory. It manifests on the client side as an InvocationException with a fantasticly unhelpful error message.

The fix is simple: copy the serialization policy file to wherever the GWT files appear to be served from.

GWT | moore |

GWT impressions

After about a year of working with GWT, it seems to me like there are two places where it is really useful as a technology:

  1. Quickly building relatively sophisticated user interfaces for entire web based applications. An intranet ‘client-server’ type application, like a timesheet, would be a perfect fit. If you use Java on the server side, domain objects can even be shared.
  2. Building small widgets that have anything beyond the simplest logic. This is the best way to integrate GWT into an existing application–add small bits of functionality that improve the user experience. You can use GWT to manage, reuse and package this logic.

However, what GWT is best for is not the limiting factor for GWT; rather, if you aren’t a Java developer, GWT just doesn’t make sense. (I’m ignoring the fact that if a user doesn’t have JavaScript enabled, GWT doesn’t make sense, since this is a failing of almost all the Web 2.0 rich user interface toolkits).

For me, being a Java developer and a fan of Eclipse, GWT is a natural fit for a number of reasons. The Java object serialization support, the use of an IDE to code Javascript, the JRE emulation, and the event driven user interface model all make it extremely comfortable to develop in the language. If you’re already coding the server side in Java, GWT is one less language to learn (until you need to do something that isn’t provided for in the emulation libraries, or you need to use a Java 1.5 feature, or a bug leaks up through the abstraction; of course, these problems will never happen).

While I don’t have deep knowledge with other toolkits (I’ve worked slightly with the Yahoo! User Inteface Library and have toyed with Dojo), it seems to me that many many folks can get by using them; there’s no tie to Java.

If someone was going to ask me whether or not they should use GWT, I’d boil it down to the following questions:

  1. Are your developers familiar with Java? (If ‘no’, don’t use GWT.)
  2. Are your developers familiar with JavaScript? (If ‘yes’, consider not using GWT.)
  3. Are you integrating with an existing app? (If ‘yes’, GWT might be a good fit.)
  4. If so, are you planning to ‘web 2.0’-ify the existing application, or add widgets to enhance existing functionality? (If planning to ‘web 2.0’-ify existing functionality, don’t use GWT.)

On a final note, I don’t want to bag on GWT too much. GWT has improved tremendously over the past year or so, and I’m very glad to have used it. I think it’s quite cool tech, and I think it has really improved the user experience on my client’s site.

Thank you, Google, for releasing GWT and making it available for me to use.

Dynamic Languages GWT Java YUI | moore |

Beware collections with GWT 1.4 Final

I just upgraded our application to GWT 1.4.60, aka 1.4 Final. The upgrade was for the most part, pretty smooth. Only one issue reared its head. I have a number of objects that are Serializable that contain other Serializable objects. I had not marked them with the @gwt.typeArgs javadoc metadata, and things had worked just fine in GWT 1.4.10 (RC1). However, with 1.4 Final, I kept getting an InvocationException.

These tend to be real pains, because I’ve never seen them raised in code I write. Instead, they seem to arise from misconfiguration. Last time I saw one, I was compiling against the wrong version of gwt-servlet.jar.

This time, I hadn’t marked the contents of various Sets and Maps with the contents (using the aforementioned @gwt.typeArgs markup). I received warnings at compile time about that, but had received warnings with RC1 as well. I had, in typical developer fashion, noticed that the code still worked and thus ignored the warnings.Putting that markup in my code seemed to solve the problem.

There’s one thread on the groups about something similar to this. Here’s the tracking issue.

GWT | moore |

GWT 1.4 thoughts

I’ve been working with GWT 1.4 RC1 for the past few months. I’ve really enjoyed a number of things about this release, including some of the new widgets (the auto suggest box is pretty cool), and the size decrease (we saw size decreases of 20% without changing a bit of code). More on the release in the release announcement.

However, the number one reason you should upgrade to 1.4 is that it allows you to share value objects between the GWT view throughout the entire Java stack, all the way down to Hibernate (or whatever other data access layer you use). The reason is that java.io.Serializable is now a synonym for IsSerializable, the marker interface for Java objects that can be sent to the client. Obviously, if you are not using the RPC mechanism, this is much less important.

There is still some doubt about the GWT 1.4 release date, but you can check out the auto suggest box in action at Colorado HomeFinder (the browse homes link in the nav bar). I think this will be a killer release when it finally happens.

GWT | moore |

Initialize your GWT widgets

I’m a big fan of using GWT to increase web application usability in an incremental fashion. It may be fine to use GWT to build a whole-blown application, but I’ve never done that. When you go the widget approach, often you want to configure the widget, perhaps based on the page it is on. Kevin Jansz talks about how to give a GWT module init params (very much like init-param elements in web.xml). He suggests using the Dictionary class, which is in the i18n module. For a sweet example (that is not even related to i18n), read the Dictionary doc linked to above.There are some caveats. From the aforementioned documentation:

…the Dictionary class is fully dynamic. As a result, a variety of error conditions (particularly those involving key mismatches) cannot be caught until runtime. Similarly, the GWT compiler is unable discard unused dictionary values since the structure cannot be statically analyzed.

To me, using a Dictionary is a better way of getting configuration information from a host page than what I’ve done in the past: write a value to a hidden span and use the DOM GWT class to access it. Much clearer and no unneeded DOM elements. In fact, if you wanted to get fancy, you could generate the javascript object properties dynamically (this is conjecture, I’ve not tested this).

Nice find Kevin!

GWT Web Applications | moore |

Transcript of GWT talk

Here is a transcript from a tech talk about GWT by Bruce Johnson, who is apparently a tech lead over at Google. It’s from a TheServerSide.com tech talk.  You can view the video as well (I guess–I didn’t). Some very interesting stuff in there, even though it’s about two months old. Here are some excerpts I found interesting.

On why Java was chosen for javascript development:

We want a more mature language [than javascript]. The Java language has a lot of years on it now. We have a lot of developers that know Java. There are a lot of books, other supporting technologies, things like debuggers and JUnit, and there is a tool called ‘FindBugs’ which does static analysis. Have you guys heard of FindBugs? It is fantastic. It is like Lint on steroids. So, you really just point it at your Java source code and it says, ‘Oh, by the way, here is like 200 bugs,’ and actually most of them are really truly bugs. Code coverage, Javadoc, really good things, all available out of the box if you use Java.

FindBugs has an eclipse plugin, by the way.

On integrating GWT into existing applications:

Probably the single biggest thing that we have screwed up so far when telling people about GWT is all these demos are like from scratch demos, and we have worked so hard to make sure that you did not have to write applications from scratch to use GWT. So, I think so far that is the biggest flub. GWT does not require you to start over. So, for example, if you have a wizzy travel service application for example that is say, based on JSP, all you need in order to add GWT logic to a page is to drop a meta tag into your head and then have a DIV or multiple DIVs that act like place holders for where you want to insert GWT behavior, which means that your Java source could not be more loosely coupled with the page. Basically, it is only connection of the page is based on ID and then, however, many assumptions you want to make.

I’ve definitely found the above to be the truth. Using GWT to build standalone components is a low risk way to explore the technology and add value to your website.

All in all, an interesting talk, err, read. (Here’s another talk by Bruce on TSS.)

GWT | moore |

XHR Data Caching and the Dojo Offline Toolkit

I’ve found caching JSON to be very useful when writing GWT components. Basically, the XMLHttpRequest will go to the browser cache first, and if the data is (relatively) static, you can direct the browser to cache it. More about caching in this post. If the browser hasn’t seen that url before, it will get it from the server. Using some kind of rewrite tool to make sure the data page looks like a normal HTML page tends to be good form.

But the Dojo Offline Toolkit promises to take things to a whole new level. It’ll be interesting if he succeeds. I took a look at his milestone list, and there are a number of ‘Figure Out’ steps, as you’d expect with something this ambitious and new. Well worth looking at if you write web applications of any kind.

[tags]data caching,dojo,offline web applications[/tags]

GWT Web Applications | moore |