GRAILS.IO

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

Fri, 17 May 2013 12:04:00 +0200

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...

Fri, 10 May 2013 10:09:09 +0200

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

Grails 2.3 M1 and Upcoming M2

Fri, 10 May 2013 10:07:41 +0200

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"?

Mon, 22 Apr 2013 09:37:00 +0200

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

Tue, 19 Mar 2013 20:54:36 +0100

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.save(flush:true)    
    }
}
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("http://download.finance.yahoo.com/d/quotes.csv?s=${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) {
    asyncBookService.findBooks(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.

Little Goblin: Grails-based browser game framework

Tue, 19 Feb 2013 22:53:46 +0100

Little Goblin: Grails-based browser game framework:

Interesting project to create a browser game framework for Grails

Road to Grails 2.3: Forked Execution

Tue, 19 Feb 2013 15:02:37 +0100

In previous versions of Grails everything we did has been in-process. In other words, when you run something like ‘grails run-app’ the Tomcat container would live in the same JVM process as the ‘grails’ command. Likewise if your run ‘grails test-app’ the tests are run in the same process as the ‘grails’ command

This has several issues, some of which are listed below:

Memory strain - since the build system and the container share the same process, this puts memory pressure on the single JVM process making it hard to identify at development time your applications memory requirements
Classpath isolation - build time only dependencies “leak” into your application. So your application sees classes that were only meant to be seen by the Grails build system. This can lead to behaviour that worked during ‘run-app’ but failed upon WAR deployment.
MetaClass conflicts - This is a particular issue of a dynamic language like Groovy. If you modify the MetaClass of a class, a quite common practise during testing for example, this change is seen JVM wide. Quite a few people have stumbled into issues running ‘test-app’ whilst the container was running (from interactive mode) and seeing their running applications behaviour change.

So as you can see in retrospect allowing everything to happen in a single process was a design error in the framework from the beginning.

So in Grails 2.3 we are changing Grails to fork a new process for things like run-app, run-war and test-app. You will still be able to revert back to running in the same JVM if you rely on the previous behaviour (not something we recommend), but the default will be forked execution. The parameters to the forked JVM can be controlled via configuration in BuildConfig.groovy which defaults to:

 
forkConfig = [maxMemory: 1024, minMemory: 64, debug: false, maxPerm: 256]
grails.project.fork = [
   test: forkConfig, // configure settings for the test-app JVM
   run: forkConfig, // configure settings for the run-app JVM
   war: forkConfig, // configure settings for the run-war JVM
   console: forkConfig // configure settings for the Swing console JVM
]

You can tweak the memory and debug requirements of the forked JVM as needed for testing or execution of the application.

Note that one particular challenge with this new approach is that spinning up a new JVM is an expensive operation. So we have taken an approach similar to the Drip tool that maintains a pre-intialized JVM behind the scenes ready for execution.

This only works via interactive mode, so for 2.3 and above it becomes even more important to start Grails with the ‘grails’ command and then run ‘test-app’ from interactive mode. When starting interactive mode Grails will keep a pre-intialized JVM running in the background to quickly execute unit tests. In our testing there is not a noticeable difference in performance between this approach and running tests inline in the same JVM.

Lookout for the new forked execution feature in Grails 2.3 M1, which we are targeting for release within the next few weeks.

Road to Grails 2.3: Improved Dependency Resolution

Wed, 09 Jan 2013 15:21:02 +0100

During the various Grails conferences last year (2GX, Gr8conf, Grails Exchange etc.) there were significant numbers of people who commented that dependency resolution was their biggest problem with Grails.

We’ve made improvements in this area already, in Grails 2.1 we introduced proper Maven support, but that still requires you to use the Maven build tool. Folks using the normal Grails command line have been stuck with Ivy. Starting with the upcoming Grails 2.3 release you will be able to switch to Aether as the default dependency manager by adding the following line to your BuildConfig:

grails.project.dependency.resolver = “maven”

What is Aether? Aether is the dependency resolution library used by Maven itself for resolution. What this means is that several problems users have had with Ivy go away, including:

Problematic snapshot handling (Ivy doesn’t deal with snapshots the same as Maven)
Issues with different packaging types used in POMs
Lack of support for repository URLs in POMs (although this is discouraged)
Problems with complex POMs and classifiers

In addition to this, to help users diagnose dependency resolution failures we have shamelessly borrowed/stolen Gradle’s dependency graph output for Grails’ dependency-report command:

And when you get dependency resolution failures you get nice output highlighting the dependency that failed to resolve:

There have been numerous internal framework improvements as well to reduce the number of dependency, cleanup Grails’ transitive dependencies and ensure issues like 2 plugins with the same version conflicting don’t happen.

Of course, we still have on the roadmap to move to Gradle in Grails 3.0, but in the meantime Grails 2.x users should have something to look forward to ease any dependency resolution woes.

Grails Unit Testing and a little fun with @Before

Wed, 02 Jan 2013 10:44:03 +0100

Grails Unit Testing and a little fun with @Before:

Interesting post, the unpredictable ordering of JUnit @Before methods is a real problem. Anyone know a solution to this for JUnit 4?

Grails 2.2 Released!

Thu, 20 Dec 2012 16:09:55 +0100

Grails 2.2 Released!

Excellent Building Google Calendar in Grails Tutorial Series

Tue, 13 Mar 2012 16:19:11 +0100

Excellent Building Google Calendar in Grails Tutorial Series:

Craig Burke has put together an excellent series demonstrating building a Google Calendar type application using Grails and jQuery.

The MongoDB NoSQL Database Blog: Groovy on Grails in the Land of MongoDB

Thu, 01 Mar 2012 09:08:33 +0100

The MongoDB NoSQL Database Blog: Groovy on Grails in the Land of MongoDB:

mongodb:

Groovy and Grails’ speed and simplicity are a perfect match to the flexibility and power of MongoDB. Dozens of plugins and libraries connect these two together, making it a breeze to get Grooving with MongoDB.

Using Grails with MongoDB

For the purpose of this post, let’s pretend we’re writing a…

Grails 2.0.1 Available...

Tue, 14 Feb 2012 18:09:42 +0100

Today we put out Grails 2.0.1, we’ve been keeping our eyes open for folks who are having trouble upgrading and trying to proactively fix the issues that people encounter during an upgrade.

Grails 2.0.1 is the result of that work and includes over 80 bug fixes and improvements, hopefully paving the way for more folks to upgrade.

Let us know if you’re having trouble and we’ll prioritize the issue.

Chronic iMac Wifi Kernel Panics in Lion

Fri, 10 Feb 2012 12:31:12 +0100

Dear Apple, I want to like Lion I really do, but as of today I cannot recommend anyone upgrading to it if you own an iMac (mid 2011). I personally am going to downgrade to Snow Leopard at the next available opportunity.

There are chronic Wifi related kernels panics that are seemingly going unaddressed by Apple. I personally have 3 or 4 kernel panics per day (using 10.7.3). There are multiple threads on the topic in the Apple support forums. Some schools have dozens of machines impacted. This is not an isolated problem. Some have indicated that replacing the Lion Wifi driver with the Snow Leopard one resolves the problem. Not for me.

It seems the only way to have a stable iMac system with Lion is to disable Wifi. Completely unacceptable that, considering the issue doesn’t occur if I run Windows in Bootcamp and didn’t occur with Snow Leopard.

Apple please, sort it out. Rant over.

O'Reilly: Mastering Grails 101 Video

Thu, 02 Feb 2012 09:45:00 +0100

O'Reilly: Mastering Grails 101 Video:

Check out this 3 hour+ screencast of starting out with Grails 2.0 by the excellent duo Tim Berglund and Matthew McCullough. Nice to see some professional level screencasts out there.

Call for testing of existing Maven plugin

Wed, 01 Feb 2012 11:27:54 +0100

If anybody out there has the time please test out Maven plugin for Grails 2.0 and report back any issues. Instructions for setup can be found here.

Nice installing Grails 2.0 on OS X screencast for beginners. See...

Tue, 31 Jan 2012 20:01:59 +0100

Nice installing Grails 2.0 on OS X screencast for beginners. See also Installing Grails 2.0 on Windows for those less fortunate.

Functional testing Grails core with Gradle, Spock and Geb

Wed, 18 Jan 2012 17:34:00 +0100

Today I pushed a new functional test suite for Grails that is based on Gradle, Spock and Geb.

I have been relatively frustrated with our existing functional test suite and wanted to modernize it to take advantage of all the latest innovations happening in the Groovy testing community.

The requirements fulfilled by the new test suite are as follows:

Allow tests to be created in a standard Gradle structure
Allow tests to be run from the IDE
Enable easy scripting of the Grails command line
Enable easy web function testing of the running application

An example of what I came up with can be seen below:

 class RunAppSpec extends BaseSpec { void "Test run-app starts correctly"() { given:"A new project" grails { createApp "test" runApp() } when:"The home page is requested" go "" then:"The Grails welcome page is shown" title == "Welcome to Grails" } }

As you can see the Grails command line can be easily scripted with the grails block. Then testing of web UIs is left to Geb’s DSL.

Hopefully this will also make it easier for folks to contribute functional tests. Please feel free to fork the repository and send us a pull request!

Object Partners posted a nice presentation on what is new in...

Wed, 18 Jan 2012 10:27:35 +0100

Object Partners posted a nice presentation on what is new in Grails 2.0.

Lessons learnt developing Groovy AST transformations

Mon, 16 Jan 2012 21:59:00 +0100

Updated 17/01/2012: Info on handling exceptions

During the development of Grails 2.0 we shifted a significant amount of meta-programming logic to Groovy AST transformations.

The advantages of AST transformations are several. More flexible DSLs can be created, you don’t pay a runtime startup cost to use these DSLs and as a framework developer you can inline method calls where necessary.

Having said that Groovy AST development has its dark sides and below I’m going to list some lessons learnt developing AST transforms:

1. Avoid Global Transforms

Global AST transformations have their place, but they also have limitations. Their order is undetermined, you cannot have dependencies between transformations and they tend to be more difficult to debug.

We ended up rolling our own equivalent to global transforms using Spring class path scanning and other the Spring Ordered interface to control ordering.

2. Write Utility Methods

AST transformation code can be very repetitive. We ended up coming up with GrailsASTUtils as well as a series of base classes to make common transforms easy. Things like adding a method that delegates to property (like Groovy’s @Delegate) or the equivalent of Java reflection APIs for introspecting ClassNode instances are available via GrailsASTUtils.

We also wrote an alternative to Groovy’s @Delegate called ApiDelegate that allows you to get a reference to the delegating instance and honors any annotations found in methods of the delegate.

3. Don’t Reuse AST nodes

Say you have a reference to a ClassNode instance obtained by inspecting the AST you’re transforming. Do NOT under any circumstances use this ClassNode to add a new method or property to the class being transformed. Doing stuff like:

 
  MethodNode fooMethod = classNode.getMethod("foo", new Parameter[0]) 
  classNode.addMethod( new MethodNode("newMethod",                                       
                                       Modifier.PUBLIC, 
                                       fooMethod.getReturnType(),                                       
                                       new Parameter[0],                                      
                                       new ClassNode[0],
                                       methodBody);  ) )

Where you are reusing the ClassNode returned from getReturnType() is very dangerous and lead to all sorts of generics related errors. Always create a new ClassNode reference from an existing one using ClassHelper:

 
  MethodNode fooMethod = classNode.getMethod("foo", new Parameter[0]) 
  classNode.addMethod( new MethodNode("newMethod",                                       
                                       Modifier.PUBLIC, 
                                       ClassHelper.make(fooMethod.getReturnType().getName()),                                       
                                       new Parameter[0],                                      
                                       new ClassNode[0],
                                       methodBody);  ) )

The above using of ClassHelper.make(..) will save you loads of time, trust me.

4. Get comfortable with byte code and decompilers

Nobody said writing AST transformations was for the feint hearted and if you’re going to write any non-trivial transform you’ll need to get comfortable with using javap and a Java decompiler just in case something goes wrong in the byte code generation phase.

I recommend JD-GUI for byte code decompilation and easy viewing. Whilst javap is fine for seeing the raw byte code.

5. Never throw Exceptions from an AST transform

The Groovy compiler really doesn’t like it if you throw an exception from an AST transform. It also results in ugly errors to the user of your transform.

The proper way to report an error is via the SourceUnit which has an errorCollector property:

 
String messageText = "You can only negate a binary expressions in queries."
Token token = Token.newString(
                       expression.getText(),
                       expression.getLineNumber(), 
                       expression.getColumnNumber())
LocatedMessage message = new LocatedMessage(messageText, token, sourceUnit)
sourceUnit
   .getErrorCollector()
   .addError(message);

This will properly report a compilation error to the user. Notice too how you can pass information about the current expression node (line number, column number etc.) so that the compiler reports the location of the error nicely to the user.

Example AST Transforms in Grails

Finally, I thought I would list some of the AST transforms and what they do in Grails if you wish to see some examples in action:

DetachedCriteriaTransformer - powers Grails 2.0’s new where queries.
GormTransformer - wires in all of the GORM methods into each domain class’ byte code
ControllerActionTransformer - transforms controller methods so that request parameters get auto-bound to method arguments
ControllerTransformer - wires in the request, response, params etc. objects that form the controllers API
GormToJpaTransform - Transforms a GORM entity to a JPA annotated entity at the byte code level. Part of the new GORM-JPA plugin.