GWT RPC integration with Spring

Recently I started studying GWT, a new web framework for my curriculum. The main idea of GWT is to let you code the GUI part in Java (with static compilation and type checking) then translate this code into Javascript.

For the backend, GWT relies on an RPC system using plain old Servlet. Each RPC service is published as a distinct servlet so you end up having as many servlets are there are distinct RPC services.

Not only this approach is not optimal for resources management server-side wise, it also pollutes your web.xml with many servlet declarations.

Ideally we should have an unique servlet serving as a router and dispatching RPC calls to appropriate service beans managed by Spring. Spring is an appropriate framework for managing business in the backend due to its industry-wide adoption and its mature extensions portfolio. Needless to say that this design can be easily adapted for JEE containers too.

Disclaimer: the code presented below has been inspired from projects like spring4GWT and gwtrpc-spring. I took the same approach and modified the URL mapping part so the original credits go for them.

I SpringRPCDispatcherServlet

RPC processing with GWT not only consist of calling the appropriate service in the backend. It also involves some plumbing tasks like object serialization/deserialization to pass parameters back and forth. Instead of re-inventing the wheel and re-coding everything from scratch, it is wiser to re-use the existing GWT infrastructure and extends the RemoteServiceServlet class to adapt it to our needs.

public class SpringRPCDispatcherServlet extends RemoteServiceServlet
	private static final long serialVersionUID = 1L;
	private static final Log logger = LogFactory.getLog(SpringRPCDispatcherServlet.class);
	private static final String SERVICE_URL_MAPPER = "serviceURLMapper";
	private static final UrlPathHelper pathHelper = new UrlPathHelper();

	private WebApplicationContext applicationContext;
	private Map<String, RemoteService> springRPCServices = new HashMap<String, RemoteService>();

	public void init()
		applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
		if (applicationContext == null)
			throw new IllegalStateException("No Spring web application context found");

		if (StringUtils.isEmpty(this.getInitParameter(SERVICE_URL_MAPPER)))
			throw new IllegalArgumentException("The servlet SpringRPCDispatcherServlet should have a '" + SERVICE_URL_MAPPER + "' parameter defined");
			String beanName = this.getInitParameter(SERVICE_URL_MAPPER);
		}"SpringRPCDispatcherServlet deployed");

	private void initServiceURLMapper(String beanName)

		this.springRPCServices = (Map<String, RemoteService>) applicationContext.getBean(beanName, Map.class);

	public String processCall(String payload) throws SerializationException
			RemoteService handler = retrieveSpringBean(getThreadLocalRequest());
			RPCRequest rpcRequest = RPC.decodeRequest(payload, handler.getClass(), this);
			if (logger.isDebugEnabled())
				logger.debug("Invoking " + handler.getClass().getName() + "." + rpcRequest.getMethod().getName());
			return RPC.invokeAndEncodeResponse(handler, rpcRequest.getMethod(), rpcRequest.getParameters(), rpcRequest.getSerializationPolicy());
		catch (IncompatibleRemoteServiceException ex)
			logger.error("An IncompatibleRemoteServiceException was thrown while processing this call.", ex);
			return RPC.encodeResponseForFailure(null, ex);

	protected RemoteService retrieveSpringBean(HttpServletRequest request)
		String serviceURL = extractServiceURL(request);
		RemoteService bean = getBeanByServiceURL(serviceURL);

		if (logger.isDebugEnabled())
			logger.debug("Bean for service " + serviceURL + " is " + bean.getClass());
		return bean;

	private String extractServiceURL(HttpServletRequest request)
		String service = pathHelper.getPathWithinServletMapping(request);
		if (logger.isDebugEnabled())
			logger.debug("Service for URL " + request.getRequestURI() + " is " + service);
		return service;

	private RemoteService getBeanByServiceURL(String serviceURL)
		if (!this.springRPCServices.containsKey(serviceURL))
				throw new IllegalArgumentException("Spring bean not found for service URL: " + serviceURL);
		return this.springRPCServices.get(serviceURL);

Let’s analyze the code step-by-step.

As private fields, we declare a UrlPathHelper (line 6) to extract paths from URL (necessary to determine which service bean to call) and a map linking a serviceURL to the appropriate Spring bean (line 9).

First in the init() method (line 12) we get a reference on the current Spring Web application context. We check for the presence of the “serviceURLMapper” servlet parameter. If it’s set we initialize the map of serviceURL by calling the method initServiceURLMapper() (line 27). This method simply retrieve the map from Spring context.

At runtime, when a request is sent to the servlet, the processCall(String payload) method is called. This method is copied from the original RemoteServiceServlet class and I introduced some modifications.

  • retrieveSpringBean() is called to get the appropriate Spring service bean for the current request (line 44)
  • retrieveSpringBean() first calls extractServiceURL() which relies on the UrlPathHelper class to extract the path from servlet context (line 74)
  • then a lookup is performed by getBeanByServiceURL() in the springRPCServices map to retrieve the correct Spring bean to service the request

Please notice that the UrlPathHelper is of great help here to extract the path excluding the leading servlet context. The Javadoc of this class gives some examples to clarify its operation:

servlet mapping = “/test/*”; request URI = “/test/a”, result = “/a”
servlet mapping = “/test”; request URI = “/test”, result = “”
servlet mapping = “/*.test”; request URI = “/a.test”, result = “”

Now that we’ve created the servlet, let’s see how it is configured with GWT


II Configuration

A web.xml

A typical web.xml configuration for the SpringRPCDispatcherServlet is

<web-app xmlns:xsi="" xmlns="" xmlns:web="" xsi:schemaLocation="" version="2.5">

  <!-- Spring classical web application context declaration -->

   <!-- SpringRPCDispatcherServlet declaration -->

  <!-- SpringRPCDispatcherServlet servlet mapping -->

The first part of this web.xml is a classical Spring web application context declaration, nothing special.

Next we define our special servlet, providing the serviceURLMapper parameter. This value should point to an existing bean id in the Spring context (see below) (lines 17-18).

Finally we associate this servlet with the url pattern “/stockWatcherRPC/rpc/*” (line 26). Only RPC calls using this pattern will be handled by our custom servlet.


B applicationContext.xml

Below is the declaration of Spring beans servicing RPC requests from the GUI:

<bean id="stockPriceRPCService" class=""/>

<bean id="randomizeRPCService" class=""/>

<util:map id="serviceURLMapper" key-type="java.lang.String" value-type="">
	<entry key="/stockPrices" value-ref="stockPriceRPCService"/>
	<entry key="/randomize" value-ref="randomizeRPCService"/>

The “serviceURLMapper” is just a map with key of String type representing the serviceURL and value of type representing the corresponding Spring service bean. All server-side services for GWT RPC should implement an user-defined interface which implements itself the generic RemoteService from the GWT SDK so setting it as a supertype for map value type is fine.

The map bean is quite straightforward, associating a service path with a declared bean. Please note that in the above example:

  • stockPriceRPCService will service all incoming RPC requests with URL /stockWatcherRPC/rpc/stockPrices
  • randomizeRPCService will service all incoming RPC requests with URL /stockWatcherRPC/rpc/randomize

Please note that the service URL is the map is the absolute URL removed of the servlet path defined earlier in web.xml (/stockWatcherRPC/rpc/*)


C GWT configuration

From the GWT side the configuration is quite simple:


<module rename-to="stockWatcherRPC">

public interface StockPriceService extends RemoteService

public interface RandomizeService extends RemoteService


D URL mapping summary

Below is a picture summarizing the way URL are handled by our servlet.


Please notice that the GWT module name (here stockWatcherRPC) should be included in the servlet mapping url. Most of RPC issues come from erronous service URLs.

Another remark about URL path segregation. We could have declare the Spring servlet mapping as /stockWatcherRPC/* and the url in the map as /rpc/stockPrices.

However associating the Spring servlet mapping to the root of GWT module name (/stockWatcherRPC) is not a good idea because any request from the GUI to retrieve static resources (images, JS files…) will trigger our custom servlet, which we do not want.

That’s why it’s a better practice to separate RPC call with a dedicated URL pattern (here rpc/*)

E Alternate URL pattern

In the above example, we use the /rpc pattern in the URL string to distinguish between client RPC calls and normal resources requests.

But another approach for RPC URL mapping is possible. What if we distinguish all RPC calls with a particular extension, like *.rpc ?

Spring servlet mapping:


Spring service URL map

<util:map id="serviceURLMapper" key-type="java.lang.String" value-type="">
	<entry key="stockPrices.rpc" value-ref="stockPriceRPCService"/>
	<entry key="randomize.rpc" value-ref="randomizeRPCService"/>


In this case, we just need to modify our servlet method extractServiceURL() to extract the trailing part with .rpc extension in the absolute URL with an RegExp:

private String extractServiceURL(HttpServletRequest request)
	String service = request.getRequestURI().replaceFirst("^.*/([^/]+."+this.rpcExtension+")$", "$1");
	if (logger.isDebugEnabled())
		logger.debug("Service for URL " + request.getRequestURI() + " is " + service);
	return service;

this.rpcExtension represents the URL extension for RPC calls (.rpc here). It should be injected in the servlet as init parameter.

III Demo

As a sample application, I took the original StockWatcher from Google tutorial and modified it to use Spring RPC beans in the backend.


The main “Add” button is calling the stockPrices service. I enriched the GUI with a “Randomize” button and introduced a new randomize service to demonstrate the servlet URL mapping feature.

All source code for this project can be found on Github at StockWatcherRPC



  1. Pingback: GWT JSON integration with Spring MVC « DuyHai's Java Blog

  2. Joe Weiner


    Nicely done- very helpful for the GWT newbie. Quick question from your experience:

    In the GWT sample code from Google, the RemoteService implementation is also an extension of RemoteServiceServlet, so you have access to inherited methods from this class and its supers in your service implementation. This is required for many things you might want to access in your service implementation, such as headers, session, context, etc.

    Was thinking (have not tried) of extending the RemoteService interface to include something like setServlet(HttpServlet), which could be called as necessary just before RPC.invokeAndEncodeResponse() in your code above. Your RemoteServices would then of course implement this extended interface and regain access to servlet methods.



    1. doanduyhai

      Hello Joe

      Of course you can extend the RemoteService with some methods of your own. For example you can define MyRemoteService to extends generic RemoteService with the extra method setServlet(HttpServlet)

      Doing that, in the processCall(String payload) method execution flow, you can set the HttpServlet to your service before RPC.invokeAndEncodeResponse() is called.

      Do not forget to change the signature of the springRPCServices field from Map<String, RemoteService> to Map<String, MyRemoteService>

      1. siva

        The blog is very helpful. Can you please provide the code snippet for setServlet(HttpServlet) and how to class this.

  3. Zahnarzt Römer

    You are so cool! I don’t believe I’ve truly read through something like
    that before. So good to discover another person with a few unique thoughts on this
    subject matter. Really.. thanks for starting this up. This website
    is one thing that is required on the web, someone with a bit of originality!

    1. DuyHai DOAN

      Thanks for appreciating.

      I’ve stopped using GWT for a while. The new trend for Web development is now pure HTML5 + JS frameworks (AngularJS, EmberJS …) for the front end and pure server technos (Java, Ruby, Node.js) for the back-end.

      The time we generate web pages from server side is gone. Frameworks like JSF, GWT, Spring MVC.. are going nowhere

  4. Pingback: GWT JSON integration with Spring MVCJava Beginners Tutorial

  5. Dżafar Sadik

    Great article about spring – gwt integration. Your solution is elegant and easy to apply. One thing you shouldn’t noticed is that HashMap isn’t appropriate for multithreaded applications. Instead you should use ConcurrentHashMap in order to ensure both thread safety and safe publication.

    1. DuyHai DOAN

      Hello Sadik

      Sure, in multi threaded environments, ConcurrentHashMap is the way to go. In the example I just want to show a simple use case, didn’t care about multi threading


Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.