Road to Grails 2.3: Milestone 2 Out Now

Two New Netflix Open Source Grails Apps

Netflix OSS is continuing to grow in its usage of Grails. Checkout Liptstick and Ice.

Web Application Development with Groovy and Grails | Harvard Extension School

Grails Academy Magazine

Mike Kelly who created those awesome screencasts at has put out a magazine on Grails for the iPad. 

Road to Grails 2.3: RESTful URL Mappings and URL Mapping Reports

In then next milestone of Grails 2.3 we’re aiming to improve the REST support significantly and part of that is improved URL mapping.

This week I pushed the updates to the implementation which includes:

  • Supports for singular and plural RESTful resources
  • Nested RESTful resources
  • Namespaces
  • Easy linking to RESTful resources

To find out more checkout the documentation updates. Oh and one final nicety is a new ‘grails url-mappings-report’ command which produces the following report (for example):


Fantastic video produced by Orange and Bronze on “Why we love Grails”

Grails 2.3 M1 and Upcoming M2

For those of you who missed the news, yes Grails 2.3 M1 is out now!

There is some great stuff in there, and fantastic contributions. Jeff Brown wrote the new Data Binding mechanism, Burt Beckwith the Hibernate 4 support and Lari Hotari did wonderful work on XSS prevention and performance optimisation.

Now we’re focusing on Milestone 2, I’m diving head first into the REST improvements, and Stephane Maldini is working on contributing the Async eventing APIs. All in all there are many exciting things coming in what will be in the final release in the 2.x line before we start on Grails 3.0!

More on “Where next for Grails”?

Last week Peter Ledbrook wrote a nice summary of where we are at and where we should be going with Grails over the next few years.

He made some interesting points, and it is true that Grails is indeed at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases.

Mobile and Rich web apps are driving this revolution. Many folks are simply serving up JSON to be consumed by rich clients. So where does Grails fit into this world? 

First of all, it is worth pointing out that Grails is not the only framework that is going to need to adapt to this new world. Pretty much every current popular web framework is going to have to make changes to support new architectural styles (including some of the official specifications from Oracle). This is already happening everywhere, and Grails is no exception.

However, unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Grails is approaching 1000 plugins, the growth Grails has had in this area has been staggering. Many of the plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

However, when you issue a “grails create-app” command, currently only one architectural style is supported: the Servlet environment.  Grails only allows creation of applications served up by a Servlet container. Granted that is a lot of applications (Tomcat is extremely popular), but we believe the features offered by Grails are compelling outside this environment too.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year.

Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create. 

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy. 

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Road to Grails 2.3: Async Support

With Grails 2.2, we introduced some basic support for accessing the Servlet 3.0 async APIs. However, we knew then that the Servlet 3.0 API wasn’t the programming model we wanted to expose to users. The reasons for this are:

  • The Servlet 3.0 APIs are servlet specific
  • Like the rest of the Servlet API they are low-level and verbose
  • The Servlet 3.0 API is just not very Groovy

Starting in Grails 2.3, we are introducing new APIs based around the notion of promises. A Promise is similar to a Java Future instance, but include a more user friendly exception handling model, useful features like chaining and the ability to attach listeners.

A basic example of promises in Grails 2.3 can be seen below

import static grails.async.Promises.*

def p1 = task { 2 * 2 }
def p2 = task { 4 * 4 }
def p3 = task { 8 * 8 }
assert [4,16,64] == waitAll(p1, p2, p3)

The above example creates 3 async tasks and then waits synchronously for them to complete. Of course, fitting asynchronous programming APIs into a full stack framework requires a lot more than exposing a nice API for programming concurrently.

From a Grails perspective, how do the Async APIs fit into controllers? How do they work with GORM? What about Transactions?

There is a whole bunch of considerations, and we’ve tried to resolve all of these within an elegant API.

With GORM, we have introduced a new “async” namespace, that allows all of the regular GORM query methods to a return a promise:

import static grails.async.Promises.*
def p1 = Person.async.get(1L)
def p2 = Person.async.get(2L)
def p3 = Person.async.get(3L)
def results = waitAll(p1, p2, p3)

Grails will automatically deal with the intricacies of opening a Hibernate session for the background thread, closing it when it is done and so on. You can even batch up multiple queries using the “task” method:

def promise = Person.async.task {
    withTransaction {
       def person = findByFirstName("Homer")
       person.firstName = "Bart"    
Person updatedPerson = promise.get()

For controllers the advantage of Servlet 3.0 Async is that using a modern container (such as Tomcat 7.0) the link between request, response and thread can be broken. By handling a request asynchronously you can return the request thread to the container, whilst keeping the response open in a non-blocking fashion. This makes modern containers far more scalable, in particular when dealing with long running requests.

With Grails 2.3 you can simply return a Promise from any action using the task method. The following example using the Yahoo Finance APIs:

def stock(String ticker) {
   task {
       ticker = ticker ?: 'GOOG'
       def url = new URL("${ticker}&f=nsl1op&e=.csv")
       Double price = url.text.split(',')[-1] as Double
       render "ticker: $ticker, price: $price"

You can also return an Async model, which is a map where the values are promises. The promises will be executed asynchronously and when ready the view rendered:

import static grails.async.Promises.*
def index() {
   tasks books: Book.async.list(),
         totalBooks: Book.async.count(),
         otherValue: {
           // do hard work

For services it is quite typical to need both a synchronous and asynchronous version of your API. Unfortunately it is tedious and error prone to maintain both. To mitigate this problem Grails 2.3 features a DelegateAsync transformation which takes any normal Grails service and exposes asynchronously.

For example take the following service:

class BookService {    
    List findBooks(String title) {
      // implementation

If you wish to expose this in an asynchronous manner simply create a new class that uses the DelegateAsync annotation:

import grails.async.*
class AsyncBookService {
   @DelegateAsync BookService bookService    

Every method from the original service will execute asynchronously returning a Promise:

AsyncBookService asyncBookService
def findBooks(String title) {
       .onComplete { List results ->
          println "Books = ${results}"    			

If the service is transactional the Promise execution will wrapped in a transaction. If you use the @Transactional annotation then the annotation attributes defined in the annotation will be used when creating the transaction.

All of this is just a preview of what is to come (if you want to find out more checkout this commit to the docs). We’re inching closer to the first 2.3 milestone release, so stay tuned for more.