This main focus is to point out some of the pitfalls which one may land into while writing the server side code for a GWT using especially when you are a beginner. Since Google’s GWT tutorial is really good and very extensive, this article is not explaining how to write code in GWT but some of the points which one needs to handle on the server side when GWT is the UI interface of the application. I am not an expert in GWT application, but just sharing my experience of integrating GWT in a web application for the first time. So you can definitely improve or suggest alternatives listed below.
The reason I have mentioned GXT also in the title is because of the similarity in issue we would face as both use GWT compiler in the background. Further I came across these problems when we started integrating GXT with our existing web application.
Handling authentication
A typical requirement of any web application is to check every request is coming from an authentic source. This involves checking either a session attribute kind of thing which is set once the user has logged in or using request headers or data to validate the user credentials. Since any decent sized application would have multiple RPC interfaces exposed (especially if different pages of an application are GWT enabled instead of the entire application), we need a kind of base servlet which is extended by all RPC servlet implementations in the application.

Once you architect your servlets into this design, the next important aspect is to hook in the authentication logic so that GWT sends the callback to appropriate method in the base servlet before executing any method in the interface implementations. Fortunately GWT already gives you such methods. The method onBeforeRequestDeserialized in RemoteServiceServlet can be overridden in the base servlet, to provide the basic authentication code of the application.
Similarly to add any custom post processing after a RPC method is executed, one can override, onAfterResponseSerialized method.
Consider the scenario when authentication fails or the user session has timed out. Typically one likes to throw some exception like AuthenticatonException. But the RPC interface method ideally should not declare such exceptions in the throws clause of the methods as it’s not really part of the method contract.
This is the first pitfall we would land up in the GWT world! Since the authentication exception is not declared to be thrown from the interface, GWT RPC framework would not add it to its Serialization Policy.
The workaround which we figured out was to inject our own serialization policy for the given exception.
Following are the implementation steps
- Create a Map with Class object as key and Boolean as value (indicating following class is to be serialized)
- Add the
Authetication Exceptionto theMap. Remember, all its parent classes have to be added explicitly to the serialization policy map. E.g. IfAuthenticationException extends RuntimeExceptionthen addRuntimeException, Exception and Throwable classes to the serialization policy map. - Declare the
StandardSerializationPolicyobject with the above map as the constructor argument.//code snippet
Map<Class<?>, Boolean> exceptionMap = new HashMap<Class<?>, Boolean(); exceptionMap.put(AuthenticationException.class, true); exceptionMap.put(RuntimeException.class, false); exceptionMap.put(Exception.class, false); exceptionMap.put(Throwable.class, false);
- Override
doUnexpectedFailuremethod ofRemoteServiceServletand if exception received inAuthenticationException, prepare the response string usingencodeResponseForFailuremethod from RPC until class passing the custom serialization policy. (Internally GWT code uses the same code with standard generated serialization policy).String responseStr = RPC.encodeResponseForFailure(null, e, preprocessingExceptionPolicy); RPCServletUtils.writeResponse(getServletContext(), getThreadLocalResponse(), responseStr, false);
That’s it. This would allow you to throw exception which are not declared by RPC interface from the callback methods.

