Over a million developers have joined DZone.

Grails View as Spring MVC View

DZone's Guide to

Grails View as Spring MVC View

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.


The reference documentation of Spring 3 contains the following statements:

One of the areas in which Spring excels is in the separation of view technologies from the rest of the MVC framework. For example, deciding to use Velocity or XSLT in place of an existing JSP is primarily a matter of configuration. This chapter covers the major view technologies that work with Spring and touches briefly on how to add new ones.

The supported views are "JSP & JSTL", "Tiles", "Velocity & FreeMarker", "XSLT". Those are the major view technologies that work with Spring. The Spring MVC stack is usually : Spring MVC + JSP/JSTL + Tiles or SiteMesh. All these tools sound outdated, always usefull but outdated. On the other side there are frameworks like JSF, Grails, Play! (not exhaustive list) which come with great views more up to date.

Grails is the most logical choice because it uses Spring MVC internally. The task should be easier. To be honest this choice is not a very hard one because Grails view is elegant.

First step : web.xml

I basicaly replace the Grails dispatcher servlet with the Spring MVC dispatcher servlet. This dispatcher takes a configuration file, usualy named servlet-context.xml. There is no other specific configuration to do.

Second step : Configuring Grails

Grails has his own directories structure which is different of a standard Java Web Application. Resources resolver depend by default on this structure. Hopefully Grails supports WAR packaging so Grails can be configured to support a standard Java Web Application directories structure.
This configuration can be done through 2 files.


This file is stored in the resources directory. It should contain :


The important line is grails.war.deployed.
Once set to true Grails resources resolver will use a WAR structure and Grails will cache GSP and not reload them. This parameter seems to be used for production mode only.


This file is stored in the groovy directory. GSP reloading can be enabled with the following line :



All the Grails taglibs cannot be used or should be used with caution. This is especially true for tags which use Grails controllers : g:form, g:link...

But creating a Grails taglib is quite easy.

Test sample

The Spring MVC controller

@RequestMapping(value = "/test")
public class TestController {

@RequestMapping(method = RequestMethod.GET, value = "/1")
public ModelAndView getCreateForm() {
Map map = new HashMap();

Account account = new Account();
account.setName("John Doe");

map.put("foo", "foo value");
map.put("account", account);

return new ModelAndView("/test", map);

The Groovy server pages

<ui:composition template="/composition">
<ui:define composition="${it}" name="menu">
<g:render template="/template" model="[testTemplate:foo]"/>

<ui:define composition="${it}" name="body">

This sample shows a Spring controller and a Groovy server pages. The GSP uses a UI composition pattern taglib I create (similar to facelet), a gsp template and a gsp layout.


The task is very easy. Nevertheless I lost quite some time on different things because of my poor Grails' knowledge. I created a custom view resolver and a custom context loader. All with some debugging to understand how Grails handles resources loading.

Nevertheless with these quite simple configurations you can use GSP as Spring MVC view. There are probably some other settings to do but for now this configuration seems to work perfectly.

The project is available on github.

In my opinion there is a big lack on the view side in the Spring MVC project. I'm really wondering what SpringSource is preparing.


Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}