The grails documentation does an OK job of describing some of the new features, but there really wasn’t anywhere that I could find that had a comprehensive list of changes you should make to your code when migrating from grails 1.3.X to 2.0.X.

This blog post is the list of changes that I wished I had when I started to migrate our code.

I found these pages helpful in figuring things out:

• The Grails 2 Testing Documentation
• Peter Ledbrook’s “Upgrade to Grails 2″ blog post
• The Grails 2 “Upgrading From Previous Versions of Grails” section of the user guide.
• Rob Fletcher’s Upgrading to Grails 2: Part 1
• This google plus thread on people’s experiences upgrading to grails 2
• GRAILS-7617 – TestFor(ControllerClass) annotation doesn’t provide renderArgs

The company I’m consulting at made a large investment in unit testing in the grails 1.2/1.3 days with 500-600 unit tests that heavily leverage custom extended base classes, `Mixin`s, and the grails 1.3 way of doing unit testing. This investment helped us keep most of our testing quick in unit tests, but has made this the most painful grails upgrade cycle I’ve been through (more painful than the grails 1.0->1.1 upgrade, which was the previous worst).

There have been surprisingly few changes to the actual production code to get things going, the vast majority of changes have been in how unit testing works.

General Test Upgrade Tips

• If you use an IDE with a debugger, it’s very useful to have a separate copy of your code that works against grails 1.3.7 so that you can have 2 instances of IntelliJ and can step through line by line in each codebase to see where things diverge.
• Methods with @Test, @Before, and @After MUST be declared public void or else they won’t be picked up
• I had real problems with using the new grails annotations (like @Mock) while extending a custom super-class, I haven’t dug to the bottom of this yet, but the grails annotations seem to have trouble with class hierarchies, avoid them if possible
• To that end, if you use the new grails annotations (like @TestFor), you MUST remove the old extends GrailsUnitTestCase
• Integration tests should also never extend GrailsUnitTestCase, they should instead extend GroovyTestCase and just use assert
• I’ve hit a number of test pollution issues when refactoring my code, where one test hasn’t properly cleaned up after itself affecting other tests downstream. If your test passes in isolation, you’ll need to run the tests in the same order as grails test-app does and slowly take out tests till your tests passes. Then you know which test is causing the pollution. The grails 2 test runner doesn’t show you the test order, but you can get it by setting a breakpoint in the JUnit4GrailsTestType.doPrepare method (line 54 as of grails 2.0.3) and executing this in your IDE: testClasses.name.each { println it }. Then you can take that list, join it together into one line and prepend grails test-app on it to run them in order.

Another way to get the in-order list of test classes from the test reports after a failed test using a little grep and sed:

grep testsuite target/test-reports/TESTS-TestSuites.xml | grep -v testsuites | cut -d\  -f8-9 | sed -E 's/name="(.*)" package="(.*)"/\2.\1/' | grep .

Mocking Class Methods by mucking with the metaClass

Groovy is now more stringent on closure arguments matching the type signature of a method it’s meant to mock. If the method you’re mocking types it’s variables, you need to match that with your closure.

grails 1.3.x:

MyDomain.metaClass.'static'.executeUpdate = { theQuery, theParams -> return}

Grails 2.0.x:

MyDomain.metaClass.'static'.executeUpdate = { String theQuery, Collection theParams -> return}

Otherwise it won’t find your closure and will still call the regular method you’re trying to mock. Put a breakpoint/println in your mocked methods to ensure that they’re being called by the code under test.

Unit Testing Domain Classes in Grails 2

mockDomain

grails 1.3.x:

class MyTests { 
    ...
    mockDomain(Person)
    mockDomain(Vehicle)

Grails 2.0.x:

@Mock([Person, Vehicle])
class MyTests {
   ...

If you’ve given mockDomain instances to save, you’ll need to save them manually now.

grails 1.3.x:

mockDomain(Person, [new Person(name: "Bob")])

If you keep the old style of domain mocking through mockDomain you need to ensure that you aren’t calling it twice on the same class (say in setUp and then again in a test method, or in a superclass and a subclass). This causes really hard to find test pollution errors downstream with the grails 2.0.3 code. It appears that it’s messing with the metaClass again and re-mocking it, but then when the test is done not fully cleaning up after both metaClass modifications. I consider this a bug as mockDomain should be idempotent; if you’ve already mocked a class calling mockDomain again shouldn’t remock the class, but this is what we have now.

Grails 2.0.x:

@TestMixin(GrailsUnitTestMixin)
@Mock([Person])
class MyTests {
    ...
    @Test public void testPerson() {
        new Person(name: "Bob").save(failOnError: true)
    ...

One caveat is that validation is now enforced on these objects, you can either pass in validate:false on the object, or use the grails BuildTestData plugin to create your valid objects:

@TestMixin(GrailsUnitTestMixin)
@Build([Person])
class MyTests {
    ...
    @Test public void testPerson() {
        Person.build(name: "Bob")
        ...

The Build Test Data plugin has recently been enhanced to work with grails unit tests, and I recommend using it’s @Build annotation in place of @Mock in pretty much every case. It just makes things so much easier by building fully valid objects automatically for you.

Controller Unit Tests in Grails 2

mockConfig

grails 1.3.x:

mockConfig """
    grails.foo.bar='baz'
"""

Grails 2.0.x:

grailsApplication.config.grails.foo.bar='baz'

mockParams

grails 1.3.x:

mockParams.foo = "bar"

Grails 2.0.x:

params.foo = "bar"

So you can replace all mockParams with just params.

mockFlash

grails 1.3.x:

assertEquals "Expected Message", mockFlash.error

Grails 2.0.x:

assert "Expected Message" == flash.error

So you can replace all mockFlash with just flash.

renderArgs and redirectArgs

The very useful renderArgs and redirectArgs mock objects are gone in grails 2.0 and I find the new way of testing without them to be harder than it was.

renderArgs.view

grails 1.3.x:

assert 'edit' == renderArgs.view

Grails 2.0.x:

assert view.endsWith('/edit')

redirectArgs

grails 1.3.x:

assertEquals 'person', redirectArgs.controller
assertEquals 'show', redirectArgs.action
assertEquals personInstance.id, redirectArgs.id

Grails 2.0.x:

assert response.redirectUrl.endsWith("/person/show/${personInstance.id}")

(or just use contains or .split('/') to find parts of the url)

renderArgs.model

grails 1.3.x:

assert renderArgs.model.person.id == person.id

Grails 2.0.x:

assert model.person.id == person.id

This seems to work unless you’re rendering a template in your controller rather than a view. In that case, the model isn’t populated and cannot be accessed as far as I can tell. This is documented in GRAILS-8659 which is marked as “Not a Bug”, something I disagree with as the workaround is much more painful.

The workaround, per Graeme Rocher on that ticket is to mock the template rendering:

views['/test/_bar.gsp'] = 'Hello ${name}'
controller.renderTemplate()
assert response.contentAsString == "Hello John"

Where controller:

def renderTemplate() {
    render template:"bar", model:[name:"John"]
}

The naming convention of what you set in the map should be in the format “/person/_editAddress.gsp”, where you’re in the PersonController and the template name is editAddress but there were a few situations where I had trouble getting this right.

If you want to be sure what value to set the path to in the views map, set a breakpoint in RenderDynamicMethod.java around like 319 where it does this check:

String templateUri = webRequest.getAttributes().getTemplateURI(controller, templateName);

The value of that templateUri is what you want to set in your views map.

redirectArgs.params

grails 1.3.x:

assert "bar" == redirectArgs.params.foo

Grails 2.0.x:

// strip off everything up till the ? that marks the start of the query string
def params = WebUtils.fromQueryString(response.redirectUrl.find(/[^?]*$/))
assert "bar" == params.foo

gross. This really should be better and usability has regressed on this.

mockResponse

grails 1.3.x:

assertEquals 404, mockResponse.status
assertEquals "foo bar baz", mockResponse.contentAsString

Grails 2.0.x:

assert 404 == response.status
assertEquals "foo bar baz", response.contentAsString

So you should be able to find/replace mockResponse with just response

mockLogging

grails 1.3.x:

mockLogging(Foo)

grails 2.0.x:

In many cases, this can simply be deleted. If it’s either the class under test (the class you are doing a @TestFor on) or something you’ve already got in a @Mock or a @Build class level annotation, it already has logging.

For those classes that need logging, but are not already mocked, you can use the grails.test.MockUtils.mockLogging static method. Just add this static import to your class to get the same behavior:

import static grails.test.MockUtils.*
    ...
    mockLogging(MyService)

If it’s a collaborator that isn’t already mocked out, you can use the mockFor method as described in the mocking collaborators section of the grails user docs.

def foo = mockFor(Foo, true) // true here is "loose" mocking, otherwise you need to `demand` method calls for them to not fail.

Overall, I’m much happier with grails 2.0. It has a number of great features and speed improvements that make it a worthwhile upgrade. I complain above about a few places where I think testing is not as easy as it was, but most of these could be remedied with a few patches to grails-core.

Having to log in manually impedes development speed.

If you watch what your browser is doing when it’s interacting with a Spring Security application, you’ll see that (by default) it’s POSTing 2 parameters (j_username and j_password) to http://localhost:8080/YOURAPP/j_spring_security_check.

It’s easy to automate the login process with a little bit of vanilla javascript. Edit this javascript url to replace YOURAPP, YOURUSERNAME, and YOURPASSWORD, then make a bookmark out of it in your browser:

javascript:(function(){var%20path='http://localhost:8080/YOURAPP/j_spring_security_check';var%20params={'j_username':'YOURUSERNAME','j_password':'YOURPASSWORD'};var%20form=document.createElement("form");form.setAttribute("method","POST");form.setAttribute("action",path);for(var%20key%20in%20params){var%20hiddenField=document.createElement("input");hiddenField.setAttribute("type","hidden");hiddenField.setAttribute("name",key);hiddenField.setAttribute("value",params[key]);form.appendChild(hiddenField);}document.body.appendChild(form);form.submit();}());

Any time you want to log in, just click that bookmark. You’re now fully authenticated and in the app without having to interact with the login page.

Alternatively, if you’re using Google Chrome (or Firefox), you can create a “search engine” associated with a user-defined keyword. Type the keyword in the address bar to launch it.

You can even parameterize it to log in as a variety of users.

Say that you’ve got a number of different test users in your app: “admin”, “joeuser”, “sales”, “finance”, etc. All of the test users have the same password, but different usernames with different roles. If you make the username in the javascript url a “%s”, Chrome will replace that “%s” with your “search term”.

So if your app is “superapp” and all passwords are “password”, you can use this to create a Chrome search engine that lets you login with whatever test user you want

javascript:(function(){var%20path='http://localhost:8080/superapp/j_spring_security_check';var%20params={'j_username':'%s','j_password':'password'};var%20form=document.createElement("form");form.setAttribute("method","POST");form.setAttribute("action",path);for(var%20key%20in%20params){var%20hiddenField=document.createElement("input");hiddenField.setAttribute("type","hidden");hiddenField.setAttribute("name",key);hiddenField.setAttribute("value",params[key]);form.appendChild(hiddenField);}document.body.appendChild(form);form.submit();}());

To set it up, go into your preferences (cmd-,) and press the “Manage Search Engines” button.

Then under “Other Search Engines” click in the box to “Add a new search engine”

Name it with your app’s name (“superapp login”), set the keyword to an abbreviation of your app’s name (“sa”), and set the url to the edited javascript command to log in with your app’s url/username/password (potentially with the username as “%s” to parameterize it).

Once you save it, you can then go to your browser’s address bar (cmd-L) and type your abbreviation (“sa”) to get a new “search engine”. Then enter the username you want to log in as.

Hit enter and you’ll automatically be logged in to your app, without having to interact with your normal login page.

Automating this can help to keep you in the zone, especially if you’re using a security framework that allows deep linking.

If deep linking is enabled, the quickest way to get back to the page you’re iterating on after your session has expired (or you’ve bounced the app) is to reload the page. As it’s redirecting you to the login page, go to your address bar (cmd-L), type your keyword (ex: “sa”) and any associated username (ex: “admin”) and hit enter. You’ll be logged in before the login page displays and Spring Security will redirect you back to the page you originally requested.

I’ve recently needed to revisit some batch importing procedures and have acquired a few extra tools in my Grails utility belt since writing that post: Grails Redis and Grails Jesque.

Redis is a very fast key/value store, where the values are not just strings, but are data structures like lists, sets, and hash maps. I’m the main author of the grails redis plugin, and it’s my favorite pragmatic technology of the past few years. If you’re new to Redis, check out the presentation slides I gave at this year’s gr8conf.

Jesque is a Java implementation of Resque. A Redis-backed message queueing system for creating background jobs. The Jesque plugin is fully integrated with Grails and allows you to create worker jobs that are spring injected and have an active hibernate session. Resque was written in Ruby by the folks at GitHub.

This combination makes parallelizing work very easy, as most of the pain of trying to spin off threads in grails is handled for you by Jesque. Yes, there’s GPars, but the threads that it creates aren’t spring injected and don’t have hibernate sessions.

Using Jesque is as simple as:

1. create a Job class that implements a perform method.
2. tell Jesque to start up 1..n worker threads that monitor a queue and use your Job to process work
3. enqueue work on the queue so workers can pick it up

I’ve created a bitbucket repository with all of the source code from the original Batch Import post, as well as with the enhancements below.

The example problem is that there is a Library class that produces metadata for 100,000 books that we want to persist in the database as Book domain objects.

package com.naleid.example
 
class Book {
    String title
    String isbn
    Integer edition
 
    static constraints = {
    }
 
    static mapping = {
        isbn column:'isbn', index:'book_isbn_idx'
    }
}

The naive way of doing this takes Grails ~3 hours to do the inserts. The original batch performance post showed how to improve this time from 3 hours to 3 minutes with a few Grails and MySQL tweaks.

Using Redis + Jesque to parallelize the task, I’m able to cut that time in half again to a little over 90 seconds on my MacBook Air.

On real-world imports, where there is quite a bit more data and potentially other linked domain objects that can be memoized with the redis-plugin, I’ve seen a >100x speed improvement over the original serial import, even with the tuning tips from my original post.

Install redis and clone the test project from bitbucket to try it yourself. Just grails-run app, go to the running app on localhost and click on the link to the SerialBookController to see the original version, or the ParallelBookController to see the faster Redis+Jesque version. Each will display the length of time they took to do the insert after they’re done.

The ParallelBookController calls bookService.parallelImportBooksInLibrary(). That method spins up a number of worker threads, iterates through the books in the Library and enqueues each one on a Jesque queue. When it’s done iterating through the Library, it tells all the threads to end when they’re done processing all the work:

    def parallelImportBooksInLibrary(library) {
        Integer workerCount = 10
        String queueName = "import:book"
        withWorkers(queueName, BookConsumerJob, workerCount) {
            library.each { Map bookValueMap ->
                String bookValueMapJson = (bookValueMap as JSON).toString()
                jesqueService.enqueue(queueName, BookConsumerJob.simpleName, bookValueMapJson)
            }
        }
    }
 
    void withWorkers(String queueName, Class jobClass, Integer workerCount = 5, Closure closure) {
        def workers = []
        def fullQueueName = "resque:queue:$queueName"
        try {
            workers = (1..workerCount).collect { jesqueService.startWorker(queueName, jobClass.simpleName, jobClass) }
            closure()
            // wait for all the work we've generated to be pulled off the queue
            while (redisService.exists(fullQueueName)) sleep(500)
        } finally {
            // all work is off the queue, tell each worker to kill themselves when they're finished
            workers*.end(false)
        }
    }

The work queue that persist the Book domain objects in the database are very simple Jesque Job artefacts that are spring injected and have an active hibernate session. They can be of any class type. The only requirement is that they have a method named perform that is called and passed an item of work from the queue.

Here’s the example BookConsumerJob class that persists a Book to the database:

package com.naleid.example
 
import grails.converters.JSON
 
class BookConsumerJob {
    def bookService
 
    void perform(String bookJson) {
        bookService.updateOrInsertBook(JSON.parse(bookJson))
    }
}

You can see how simple the BookConsumerJob class is. It also calls out to the same bookService method that the serial batch import calls to import a Book.

One other neat thing about using Jesque is that it adheres to the Resque conventions for what gets stored in Redis. This means that you can gem install resque-web and then launch resque-web to get a nice monitoring platform for your Jobs and to see errors, or how much work is left in the queue.

These aliases work for both the grails as well as the grails-debug commands (for attaching a remote debugger).

If there is an application.properties file in the current directory, we can find the current version of grails for the app.

If there isn’t an application.properties file in the current directory, the script just defaults to whatever version of grails you’ve already set up as your default through the standard $GRAILS_HOME environment variable. You can use the grails symlink switching aliases that I created previously to easily move this between versions.

alias grails="execute_grails_version grails"
alias grails-debug="execute_grails_version grails-debug"
 
function execute_grails_version() {
    GRAILS_CMD=$1
    shift
    if [ -f application.properties ]; then
        export GRAILS_VERSION=`grep app.grails.version application.properties | sed -E 's/.*=(.*)/\1/'`
        export GRAILS_HOME="/usr/local/grails-$GRAILS_VERSION"
        echo "application.properties found, using \$GRAILS_HOME of $GRAILS_HOME"
    else 
        echo "application.properties NOT found, leaving \$GRAILS_HOME as $GRAILS_HOME"
    fi
 
    if [ ! -d $GRAILS_HOME ]; then
        echo "ERROR: Unable to find \$GRAILS_HOME directory at $GRAILS_HOME"
        exit 1
    fi
 
    echo $GRAILS_HOME/bin/$GRAILS_CMD $*
    $GRAILS_HOME/bin/$GRAILS_CMD $*
}

UPDATE: There are a few situations where aliases aren’t available (or are a pain to get available) such as when code is being executed as part of another application rather than from the command line. To get around this, these scripts (created by a co-worker of mine, @sjurgemeyer) could be put in your PATH, ahead of your $GRAILS_HOME/bin and used instead of the aliases above:

grails:

grails-version grails $*

grails-debug:

grails-version grails-debug $*

grails-version:

GRAILS_CMD=$1
shift
if [ -f application.properties ]; then
    export GRAILS_VERSION=`grep app.grails.version application.properties | sed -E 's/.*=(.*)/\1/'`
    export GRAILS_HOME="/usr/local/grails-$GRAILS_VERSION"
    echo "application.properties found, using \$GRAILS_HOME of $GRAILS_HOME"
else 
    echo "application.properties NOT found, leaving \$GRAILS_HOME as $GRAILS_HOME"
fi
 
if [ ! -d $GRAILS_HOME ]; then
    echo "ERROR: Unable to find \$GRAILS_HOME directory at $GRAILS_HOME"
    exit 1
fi
 
echo $GRAILS_HOME/bin/$GRAILS_CMD $*
$GRAILS_HOME/bin/$GRAILS_CMD $*

The quick and dirty way to switch your logging level dynamically, if you know the name of the logger is just to do this in your console window:

import org.apache.log4j.*
Logger.getLogger("org.springframework").level = Level.DEBUG

Sometimes, a few helper methods can help you see what the current config is (especially if you’ve changed some things), as well as figure out what the right loggers are to tweak. This sample script can be used in a grails console to make it easy to view and change the logging level to whatever you want, just cut and paste it into your application’s console window (in dev it defaults to: http://localhost:8080/yourAppName/console):

import org.apache.log4j.Logger
import org.apache.log4j.Level
import static org.apache.log4j.Level.*
 
def getRootLogger() { Logger.rootLogger }
def getAllLoggers() { rootLogger.loggerRepository.currentLoggers.toList().sort { it.name } }
def getActiveLoggers() { allLoggers.findAll { it.level } }
def getLogger(String logName) { rootLogger.getLogger(logName) }
def setLevel(String logName, Level level) { rootLogger.getLogger(logName).level = level }
 
def printLogger(logger) { println "${logger.name} -> ${logger.level}" }
def printAllLoggers() { allLoggers.each { printLogger(it) } }
def printActiveLoggers() { activeLoggers.each { printLogger(it) } }

This makes it easy to see what logs are currently active (those with a log level set):

printActiveLoggers()

prints something like:

grails.app.filters.LoggingFilters -> DEBUG
grails.app.filters.SecurityFilters -> DEBUG
grails.app.service.grails.plugin.redis.RedisService -> WARN
grails.app.task -> DEBUG
org.apache.cxf -> DEBUG
...

You can also list all loggers, which also adds in those loggers who’s log level is currently `null`:

printAllLoggers()

prints:

grails.app -> DEBUG
grails.app.bootstrap.BootStrap -> null
grails.app.bootstrap.QuartzBootStrap -> null
grails.app.codec.org.codehaus.groovy.grails.plugins.codecs.Base64Codec -> null
grails.app.codec.org.codehaus.groovy.grails.plugins.codecs.HTMLCodec -> null
grails.app.codec.org.codehaus.groovy.grails.plugins.codecs.HexCodec -> null
...

You can also dynamically grab/create a logger and set it’s logging level to something more or less verbose than it’s current value:

def logger = getLogger("grails.app.service.grails.plugin.redis.RedisService")
printLogger(logger)   // initially WARN
logger.level = INFO  
printLogger(logger)   // prints INFO

prints:

grails.app.service.grails.plugin.redis.RedisService -> WARN
grails.app.service.grails.plugin.redis.RedisService -> INFO

It’d be easy to turn this into a simple gsp/controller that accepts changes and can list things out. There are also a number of other plugins out there that let you view/change logging levels (including another one of Burt’s plugins, app info), but if you don’t have those installed, this is a quick way to see what’s going on with your application.

Quick description of what Redis is from the README:

The best definition of Redis that I’ve heard is that it is a “collection of data structures exposed over the network”.

Redis is an insanely fast key/value store, in some ways similar to memcached, but the values it stores aren’t just dumb blobs of data. Redis values are data structures like strings, lists, hash maps, sets, and sorted sets. Redis also can act as a lightweight pub/sub or message queueing system.

Redis is used in production today by a number of very popular websites including Craigslist, StackOverflow, GitHub, The Guardian, and Digg.

The Grails Redis plugin makes a Redis connection pool available (and injectable as a spring bean) to your Grails application.

To install the plugin, just execute this inside your application’s directory:

grails install-plugin redis

It allows you to transparently interact with your Redis instance by automatically handling retrieving a connection from the pool and ensuring that the connection is returned to the pool as it delegates to redis.

// overrides propertyMissing and methodMissing to delegate to redis
def redisService
 
redisService.foo = "bar"   
assert "bar" == redisService.foo   
 
redisService.sadd("months", "february")
assert true == redisService.sismember("months", "february")

One of the plugin’s greatest strengths is in the memoization methods and tag libraries that it adds. It’s a write-through cache (with optional TTL expiration). Before executing the closure/tag, it will check Redis to see if we’ve already calculated that value. If we have, we’ll just return the answer from Redis, otherwise, we’ll calculate it, and save it in Redis for future calls.

service method:

redisService.memoize("user:$userId:helloMessage") {
    // expensive to calculate method that returns a String
    "Hello ${security.currentLoggedInUser().firstName}"
}

taglib:

<redis:memoize key="mykey" expire="3600">
    <!-- 
        insert expensive to generate GSP content here 
 
        taglib body will be executed once, subsequent calls 
        will pull from redis till the key expires
    -->
    <div id='header'>
        ... expensive header stuff here that can be cached ...
    </div>
</redis:memoize>

Check out the full documentation on the github repository.

If you’re new to using Redis with Groovy, I created an introductory post and gave a presentation at gr8conf that are good starting places.

If you use OSX for development, you might also find these instructions for automatically launching Redis on startup with launchd useful.

An original version of the keynote file that I presented can be found on my bitbucket account. You can download the repo or grab the raw versions off bitbucket.

• You can’t attach it to a running grails instance, you need to run grails console from scratch
• You can’t pass it parameters, such as the name of a script you’ve saved
• It’s a swing app, which is always a little wonky in it’s keybindings and it’s behavior
• It’s not <insert your chosen editor>

I got tired of these limitations so I decided to do something about it. I put together a groovy script that uses HTTPBuilder to POST groovy code to a running Grails app that has the grails console plugin installed.

If you’re running this in any non-development environment, you’ll want to ensure that it’s behind some form of authentication. The most popular grails security plugin is Burt Beckwith’s spring security core, so this script comes with built-in support for that.

This script makes it easy to call from any editor that allows you to execute scripts (pretty much every programmer’s editor on the market). At the bottom of the post, I show how to integrate it with Vim (my editor of choice), but it’d be just as easy to script it from TextMate, JEdit, IntelliJ, Eclipse, etc. Any editor that can take the file you’re currently editing and pass it to a shell script.

Here’s my Vim session with a grails script at the bottom and the output from that grails script in another window at the top.

This is the script that makes the magic happen (linked from github so any future tweaks will be reflected below), just grab a copy and save it somewhere in your path.

If you execute the script without any parameters, it’ll show you the usage syntax:

% postCode.groovy 
usage: postCode.groovy [-u username] [-p password] -b baseUrl file
 -b,--baseurl <baseUrl>     The required base url to auth/post to, ex:
                            http://localhost:8080/myapp/
 -p,--password <password>   The password to authenticate with
 -u,--user <user>           The username to authenticate with, null
                            username/password skips authentication

It uses the nifty CliBuilder that’s comes with recent versions of Groovy to parse command line arguments. If your project doesn’t have any authentication, you can simply call it with the -b argument to let it know where your app is running and pass it a script to execute on that running instance:

postCode.groovy -b http://localhost:8080/myapp/ scriptToRun.groovy 
... results of scriptToRun.groovy ...

If your project IS using the spring security plugin for authentication, you can add a username and a password to use for authentication:

postCode.groovy -u admin -p sekrit -b http://localhost:8080/myapp/ scriptToRun.groovy
... results of scriptToRun.groovy ...

The first time that you run it, it might take a little while to run because the Grape Grab annotation is downloading the HTTPBuilder jars and it’s dependencies.

UPDATE: 8/7/2011 The below is no longer necessary with the new @GrabExclude to ignore the groovy dependency.

One sort of screwy thing that I’ve found with the default Grape settings is that it really isn’t that smart about what dependencies it should download again when they’re already satisfied. This can cause a ~30 second pause every time the script is run, which is unacceptable. I posted a message on the Groovy mailing list and the tl;dr fix for it is to increase the ivy.cache.ttl.default timeout in your ~/.groovy/grapeConfig.xml file (use this as a template if you don’t have the file).

<ivysettings> 
  <property name="ivy.cache.ttl.default" value="15m"/> 
...

Example Use with Spring Security Core Plugin

Here’s a quick demo project where the console plugin is protected by the Spring Security Core plugin.

grails create-app demo-post-code
cd demo-post-code
grails install-plugin console

Install the spring-security-core plugin and create the default User and Role domain classes.

grails install-plugin spring-security-core
grails s2-quickstart com.example User Role

Edit grails-app/conf/Config.groovy and add a rule next to the other spring security configuration stating only ROLE_ADMIN users can get to the console plugin:

grails.plugins.springsecurity.controllerAnnotations.staticRules = [
   '/console/**': ['ROLE_ADMIN']
]

Now we’ll need an admin user in grails-app/conf/BootStrap.groovy that has permission to execute code in the console. Edit the bootstrap file to look like this:

import com.example.*
 
class BootStrap {
 
    def springSecurityService
 
    def init = { servletContext ->
        def adminRole = Role.findByAuthority('ROLE_ADMIN') ?: new Role(authority: 'ROLE_ADMIN').save(failOnError: true)
        def adminUser = User.findByUsername('admin') ?: new User(
            username: 'admin', password: springSecurityService.encodePassword('sekrit'), enabled: true
        ).save(failOnError: true)
 
        if (!adminUser.authorities.contains(adminRole)) UserRole.create(adminUser, adminRole)
    }
    def destroy = {
    }
}

As you can see, we’ve created an admin user with the password sekrit.

Now, create a sample script to run in the grails context, something like this:

import com.example.* 
 
println "User count = ${User.count()}"

Now run the app with grails run-app and in another terminal window execute the postCode.groovy script and give it the credentials and the base url to post it to. If you’ve got everything set up, you should see that there’s one User in the database (the admin user that we bootstrapped in :).

% postCode.groovy -u admin -p sekrit -b http://localhost:8080/demo-post-code test.groovy
 
User count = 1

Integrating With Vim

My vimscript skills are pretty much non-existent, and I’m sure there’s a better way to do this, but here’s the code that I’ve got in my .vimrc to bind F7 to executing the current buffer as plain groovy, and binds F8 to executing it as a grails script, with full binding.

Shift-F7/F8 will close the execution window. If you highlight a part of your code in visual mode, it will just post the highlighted code rather than the whole file.

You can also override the default user/password/base url in a grails session by overriding any of these values, either directly in the vimscript or by setting the appropriate environment variable:

let g:grails_user = $DEFAULT_GRAILS_USER
let g:grails_password = $DEFAULT_GRAILS_PASSWORD
let g:grails_base_url = $DEFAULT_GRAILS_BASE_URL

So to test the above script, I’d use this in my .zshrc/.bashrc/.profile:

export DEFAULT_GRAILS_USER='admin'
export DEFAULT_GRAILS_PASSWORD='sekrit'
export DEFAULT_GRAILS_BASE_URL='http://localhost:8080/demo-post-code'

and this script to temporarily change the values using the current directory for the BASE_URL and optionally passing in a user and password

# example usage from root of grails directory: grailsBaseUrlReset myUsername myOtherPassword
function grailsBaseUrlReset() {
    export DEFAULT_GRAILS_BASE_URL="http://localhost:8080/${PWD##*/}"
    echo "DEFAULT_GRAILS_BASE_URL set to $DEFAULT_GRAILS_BASE_URL"
    export DEFAULT_GRAILS_USER=$1
    echo "DEFAULT_GRAILS_USER set to $DEFAULT_GRAILS_USER"
    export DEFAULT_GRAILS_PASSWORD=$2
    echo "DEFAULT_GRAILS_PASSWORD set to $DEFAULT_GRAILS_PASSWORD"
}

You can change them temporarily in vim by changing a value for your current grails session, just hit colon and change the value:

:let g:grails_password = "reallyReallySekrit"

(or you could add them to a different file that you source independently)

Here’s the full script, just add it to your ~/.vimrc and make sure the postCode.groovy script is in your path and you should be set to go:

function! s:copy_groovy_buffer_to_temp(first, last)
  " groovy/java scripts can't start with a # and tempname's normally do
  let src = substitute(tempname(), "[^\/]*$", "vim_&.groovy", "") 
 
  " put current buffer's content in a temp file
  silent exe ": " . a:first . "," . a:last . "w " . src
 
  return src
endfunction
 
function! s:select_new_temp_buffer()
  let temp_file = tempname()
 
  " open the preview window to the temp file
  silent exe ":pedit! " . temp_file
 
  " select the temp buffer as active 
  wincmd P
 
  " set options for temp buffer
  setlocal buftype=nofile
  setlocal noswapfile
  setlocal syntax=none
  setlocal bufhidden=delete
 
  return temp_file
endfunction
 
function! Groovy_eval_vsplit() range
  let temp_source = s:copy_groovy_buffer_to_temp(a:firstline, a:lastline)
  let temp_file = s:select_new_temp_buffer()
 
  " replace current buffer with groovy's output
  silent execute ":%! groovy " . temp_source . " 2>&1 "
 
  wincmd p " change back to the source buffer
endfunction
 
au BufNewFile,BufRead *.groovy vmap <silent> <F7> :call Groovy_eval_vsplit()<CR>
au BufNewFile,BufRead *.groovy nmap <silent> <F7> mzggVG<F7>`z
au BufNewFile,BufRead *.groovy imap <silent> <F7> <Esc><F7>a
au BufNewFile,BufRead *.groovy map <silent> <S-F7> :wincmd P<CR>:q<CR>
au BufNewFile,BufRead *.groovy imap <silent> <S-F7> <Esc><S-F7>a
 
 
" set these up as environment variables on your system, or override
" per session by using ':let g:grails_user = foo'
let g:grails_user = $DEFAULT_GRAILS_USER
let g:grails_password = $DEFAULT_GRAILS_PASSWORD
let g:grails_base_url = $DEFAULT_GRAILS_BASE_URL
 
function! Grails_eval_vsplit() range
  let temp_source = s:copy_groovy_buffer_to_temp(a:firstline, a:lastline)
  let temp_file = s:select_new_temp_buffer()
 
  if strlen(g:grails_user) > 0
      " replace current buffer with grails' output
      silent execute ":%! postCode.groovy -u " . g:grails_user . " -p " . g:grails_password . " -b " . g:grails_base_url . " " . temp_source . " 2>&1 "
  else 
      silent execute ":%! postCode.groovy -b " . g:grails_base_url . " " . temp_source . " 2>&1 "
  endif
 
  wincmd p " change back to the source buffer
endfunction
 
au BufNewFile,BufRead *.groovy vmap <silent> <F8> :call Grails_eval_vsplit()<CR>
au BufNewFile,BufRead *.groovy nmap <silent> <F8> mzggVG<F8>`z
au BufNewFile,BufRead *.groovy imap <silent> <F8> <Esc><F8>a
au BufNewFile,BufRead *.groovy map <silent> <S-F8> :wincmd P<CR>:q<CR>
au BufNewFile,BufRead *.groovy imap <silent> <S-F8> <Esc><S-F8>a

If you’re not a Vim user, it should be easy to integrate with any other editor that allows you to pass the current file to a shell command and display the results. I went a little extra with the vimscript to allow it to post the current buffer (or selected lines within that buffer) without having to save to disk first.

Grails will helpfully inject fully autowired Spring service beans into my test if I ask for them. Unfortunately, if I change the metaClass of the injected service, that change persists beyond where we want it to:

class MyService {
    def myMethod() { "unmodified" }
}
 
class MyServiceTests extends GroovyTestCase {
    def myService  // injected automatically by spring/grails
 
    void testOne() {
        myService.metaClass.myMethod = {-> "modified" }
        assertEquals "modified", myService.myMethod()
    } 
 
    void testTwo() {
        assertEquals  "unmodified", myService.myMethod() // WTF!  Returns "modified", pollution from first test
    }
}

Grails services are Spring “singleton” objects. They’re not true singletons though, singleton’s are just cached in the application context and returned whenever getBean is called.

Historically, if I wanted to mock part of my service manually, I’d need to “new” up my own instance of the service and manually inject any dependencies that the service might need to function. This is both painful and fragile, if the service adds or removes dependencies, chances are that the tests are going to break.

I realized that if I could ask Grails/Spring for a new instance of the “singleton” service that I could muck with it all I wanted in my test without worrying about polluting other tests with my changes. After some digging into the grails spring support, I came up with the following method that could be added to an integration test (or integration test base class):

// spring "singleton" objects really aren't they're just cached by their application context
def getNewSingletonInstanceOf(Class clazz) {
    String beanName = "prototype${clazz.name}"
    BeanBuilder beanBuilder = new BeanBuilder(ApplicationHolder.application.mainContext)
 
    beanBuilder.beans {
        "$beanName"(clazz) { bean ->
            bean.autowire = 'byName'
        }
    }
 
    beanBuilder.createApplicationContext().getBean(beanName)
}

This method uses the BeanBuilder to construct a temporary ApplicationContext with the Grails mainContext as a parent so that other dependencies can be resolved. This method won’t work if your service has changes to how it’s wired up and configured by spring, but the majority of Grails service classes are simply autowired byName.

Here’s a more detailed example of use. Given this service:

package com.example
 
class MyService {
    def injectedService
 
    def serviceMethod() {
        return otherMethod()
    }
 
    def otherMethod() {
        return "original value"
    }
}

I’m able to generate per-test autowired instances of my service and mock out otherMethod without polluting other tests (or the Spring injected version of the bean):

package com.example
 
import grails.spring.BeanBuilder
import org.codehaus.groovy.grails.commons.ApplicationHolder
 
class MyServiceTests extends GroovyTestCase {
    def myServiceInstance  // our new
    def myService // spring injected version
 
    protected void setUp() {
        super.setUp()
        myServiceInstance = getNewSingletonInstanceOf(MyService)
    }
 
    protected void tearDown() {
        super.tearDown()
    }
 
    // spring "singleton" objects really aren't they're just cached by their application context
    def getNewSingletonInstanceOf(Class clazz) {
        String beanName = "prototype${clazz.name}"
        BeanBuilder beanBuilder = new BeanBuilder(ApplicationHolder.application.mainContext)
 
        beanBuilder.beans {
            "$beanName"(clazz) { bean ->
                bean.autowire = 'byName'
            }
        }
 
        beanBuilder.createApplicationContext().getBean(beanName)
    }
 
    void testNewSingletonInstance() {
        assertNotNull myServiceInstance // created uniquely for this test in setUp
        assertNotNull myService         // spring injected into integration test
 
        assertNotSame myService, myServiceInstance
 
        // we've got unique instances of MyService, but both are injected with the same singleton dependencies
        assertSame myService.injectedService, myServiceInstance.injectedService
    }
 
    void testMessingWithMetaClassDoesNotAffectOriginalSingleton() {
        myServiceInstance.metaClass.otherMethod = {-> "new value" }
 
        assertEquals "new value", myServiceInstance.serviceMethod()
        assertEquals "original value", myService.serviceMethod()
 
        def anotherInstance = getNewSingletonInstanceOf(MyService)
 
        assertEquals "original value", anotherInstance.serviceMethod()
    }
}

Using this technique lets you leverage Spring’s autowiring in your tests, but also gives you the flexibility to override areas not under test to improve test readability and maintainability.

I wanted the ability to define the set of properties that I wanted to override in the config file without having to call them all out explicitly in the Spring resources.groovy file. If I missed one, or if the client library that I’m using added a new one that I don’t notice, I don’t want to have to release a new version of the code just to set it.

Grails allows you to load external config files simply by defining a reference to them in Config.groovy (this code is even commented out in the default Config.groovy file that gets generated automatically with a new grails app):

grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]

After a little playing around with the BeanBuilder syntax, I was able to come up with a solution that lets me set whatever values I want in the Config file and have them set on the bean that I have Spring/Grails build.

If you have a config like this:

foo {
    foo = "bar"
    baz = 4
}

You can populate your resources.groovy with something like this to set whatever
values are set in your config file:

beans = {
    def fooMap = application.config?.foo
 
    fooBean(Foo) {
        fooMap?.each { key, value ->
            delegate.setProperty(key, value)
        }
    }
}

This will make a bean that has it’s `foo` set to “bar” and it’s `baz` set to 4.

Later, if I find that I need to set the `baz` property on the fooBean in production, I just add that in my config file and everything works without any code changes.