Peter Ledbrook

Building a Grails project with Gradle

Earlier this week, I attended Hans Dockter’s first ever Gradle course. Everything seemed to click into place and it inspired me to have another crack at writing a Gradle plugin for building Grails projects. A lot of the hard work had already been done to get the Maven plugin working reasonably well, so all I had to do was make use of the helper classes that already existed for bootstrapping the Grails build system.

So how do you use it? Simple. Here’s a basic Gradle build file (build.gradle) that you can put in the root of your Grails project:

buildscript {
    repositories {
        mavenCentral()
        mavenRepo urls: 'http://snapshots.repository.codehaus.org'
        mavenRepo urls: 'http://download.java.net/maven/2/'
    }

    dependencies {
        classpath "org.grails:grails-gradle-plugin:1.0-SNAPSHOT"
    }
}

apply id: "grails"

repositories {
    mavenCentral()
    flatDir dirs: "lib"
}

configurations {
    compile.exclude module: "commons-logging"
}

dependencies {
    compile "org.grails:grails-crud:1.2.0",
            "org.grails:grails-gorm:1.2.0",
            "org.apache.httpcomponents:httpclient:4.0",
            "org.apache.httpcomponents:httpmime:4.0",
            ":apache-solr-solrj:1.4:dev",
            ":pgptools:0.1"

    // Required by the Joda Time plugin.
    compile "org.springframework:spring-web:3.0.0.RELEASE"
    compile "org.springframework:spring-webmvc:3.0.0.RELEASE"

    // Required by the JMS plugin.
    compile "org.springframework:spring-jms:3.0.0.RELEASE"

    runtime "org.slf4j:slf4j-log4j12:1.5.5",
            "hsqldb:hsqldb:1.8.0.5",
            "postgresql:postgresql:8.3-603.jdbc3",
            "org.bouncycastle:bcpg-jdk15:1.44",
            "net.sf.ehcache:ehcache-core:1.7.1"
}

Unbelievably, that’s it! You can now execute any of the Grails commands via Gradle like so:

gradle compile
gradle create-domain-class -Pargs=org.example.Book
gradle run-app
gradle run-app -Pargs=--https -Penv=prod
gradle create-gwt-action -Pargs="--shared-pkg=client org.example cmd ListBooks"

The -Pargs option allows you to pass any arguments you want to the corresponding Grails command, while -Penv allows you to override the default environment. In case you’re wondering, the -P option allows you configure project properties. args and env are simply two that are understood by the Grails plugin.

So what’s happening in this build file? First of all, we use the buildscript {} section to configure the plugin as a dependency of the script. Once the plugin is on the classpath, we can apply it to our build via apply id: 'grails'. Alternatively, you could download the plugin JAR file and put it into $GRADLE_HOME/lib.

The rest of the build file is concerned with setting up the dependencies for our Grails project. Quite a few are declared in this example, but the only requirement is that you declare dependencies on at least one Grails module, a logging implementation, and the JDBC driver(s) for whatever database(s) you’re using. If you’re using the Hibernate second-level cache, you should also include EhCache or OSCache.

The true beauty of this plugin is that *all* the Grails commands are available to you, including those provided by plugins. This is far better than the Maven plugin, which has a set of hard-coded goals for the most common Grails commands and a generic exec goal for executing arbitrary Grails commands. I haven’t tested all of the commands, so feel free to report any problems.

The code for the plugin can be found on GitHub. I think you’ll be surprised at how little code there is. In fact, there are only two files: build.gradle in the root of the project, and GrailsPlugin.groovy under src/groovy. I definitely recommend taking a look at the plugin file to see how Gradle’s dynamic tasks made it so easy to support all the Grails commands.

Give it a go and see what you think!

Update First off, the plugin currently only works with Grails 1.2.0+ and Gradle 0.9 snapshots. Second, I’m aware that the build script doesn’t work at the moment. Unfortunately, there appears to be a Gradle bug preventing the fixed build script from working. Stay tuned.

Update 2 My bad. The version of mavenRepo that takes more than one repository URL expects the first one to contain the POM, while the other ones are for getting hold of the JARs. I have corrected the example build so that it has separate mavenRepo lines for the Codehaus Snapshots repository (for the plugin) and the java.net repository (for GParallelizer),

Update 3 I have uploaded a new version of the plugin that allows you to start from scratch. Create a new directory for your Grails project and add the following build.gradle file to it:

buildscript {
    repositories {
        mavenCentral()
        mavenRepo urls: 'http://snapshots.repository.codehaus.org'
        mavenRepo urls: 'http://download.java.net/maven/2/'
    }

    dependencies {
        classpath "org.grails:grails-gradle-plugin:1.0-SNAPSHOT"
    }
}

apply id: "grails"

version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
    flatDir dirs: "lib"
}

configurations {
    compile.exclude module: "commons-logging"
}

dependencies {
    compile "org.grails:grails-crud:1.2.0",
            "org.grails:grails-gorm:1.2.0"

    runtime "org.slf4j:slf4j-log4j12:1.5.5",
            "hsqldb:hsqldb:1.8.0.5",
            "net.sf.ehcache:ehcache-core:1.7.1"
}

From the new directory, run gradle init and a fresh Grails project will be created for you.

Securing a GWT Grails app with Shiro

A recent poster on the Grails user mailing list asked how to secure a GWT application using Shiro. The Shiro Plugin is mostly designed to work with Grails controllers and GSPs, so that’s what the current documentation targets. GWT is a different kettle of fish, so can the Shiro Plugin help here?

As it happens, I needed to handle unauthenticated GWT requests myself recently. Here’s the solution I came up with.

Imagine we have a GWT-RPC request come in to the server, but the session has timed out. First off, is the request protected? That depends on how you have your security filters configured. I currently have this:

class SecurityFilters {
    def filters = {
        ...
        gwt(controller: "gwt", action: "index") {
            before = {
                accessControl { true }
            }
        }
        ...
    }
}

Because I’m protecting the “gwt” controller, all GWT-RPC requests require an authenticated (or remembered) user. That means whenever the current user’s session times out, Shiro kicks in and asks for authentication. It does this by redirecting to the login page, but this doesn’t work within the context of a GWT-RPC request. So what can you do?

The Shiro plugin allows you to customise the behaviour when the user requires authentication. Simply implement the following method in your filters class:

class SecurityFilters {
    ...
    def onNotAuthenticated(subject, filter) {
        if (filter.request.contentType?.startsWith("text/x-gwt-rpc")) {
            filter.render(text: "", status: 401)
            return false
        }
        else {
            // Not an AJAX request, so continue with the default behaviour.
            return true
        }
    }
}

If this method is implemented, the plugin calls it whenever authentication is required. In this particular case, I return a status of 401 (Unauthorized) if the request is of type GWT-RPC. Otherwise, I trigger the default behaviour (redirection to the login page) by returning true. In other words, the return value of the method determines whether the default behaviour occurs or not.

Note The return value of onNotAuthenticated() only has an effect in version 1.1-SNAPSHOT and greater of the plugin.

That’s it for the server side. All we need to do now is handle the 401 response on the client. How you exactly do this depends on your approach to GWT requests, but the basic mechanics are the same. I use the action handler mechanism supported by the plugin, along with Google Gin, so I can simply wrap the standard action service with a version that handles 401 responses:

public class SecureActionService implements GwtActionServiceAsync {
    private final GwtActionServiceAsync actionService;

    @Inject
    SecureActionService(final GwtActionServiceAsync actionService) {
        this.actionService = actionService;
    }   

    public <T extends Response> void execute(final Action<T> action, final AsyncCallback<T> callback) {
        actionService.execute(action, new AsyncCallback<T>() {
            public void onFailure(Throwable caught) {
                if (caught instanceof StatusCodeException &&
                        ((StatusCodeException) caught).getStatusCode() == 401) {
                    // Authentication/authorisation failure. Assume
                    // authentication at this stage and redirect to
                    // login page.
                    final String loginUrl = GWT.getHostPageBaseURL() + "login";
                    Window.open(loginUrl, "_self", "");
                }
                else {
                    callback.onFailure(caught);
                }
            }

            public void onSuccess(T result) {
                callback.onSuccess(result);
            }
        });
    }
}

Now all the client code that has the action service injected gets the custom secure service instead. This particular implementation isn’t ideal because it redirects to the standard login page for a 401, whereas it would probably be better to have a simple login popup that then resends the action on successful authentication. However, the key point is that you need to implement the onFailure() method and check for a StatusCodeException. You can then do whatever you want with a 401 response.

The solution outlined above is fairly basic, particularly as it doesn’t deal with unauthorised (as opposed to unauthenticated) access, but it should provide you with a suitable starting point to implement your own solution. You can also see how powerful the command pattern is combined with the dependency injection provided by Google Gin.

One last thing to mention: all the above is geared towards GWT-RPC. If you prefer to use JSON for the client-server communication, then you’ll need a different approach. I have no experience yet on that side of things, but you should be able to check the HTTP headers in onNotAuthenticated to determine whether a request is from GWT or not. Alternatively, simply check for the JSON content type.

‘in’ the groove

I’m sure most of you are aware of the standard Groovy for loop:

for (i in 0..<10) {
    ...
}

It can also iterate over lists:

for (name in listOfNames) {
    ...
}

For many people, that’s where the story of in ends. But did you know that it can be used in conditions as well? Try this:

assert 5 in 0..<10
assert 5 in 0..5
assert !(5 in 0..<5)
assert 5 in [ 1, 4, 5, 7, 8 ]
assert !(5 in [ 1, 2, 4, 7, 8 ])

So it works for ranges and lists. Of course, it also works for sets. And not just numbers, but all objects (because they implement equals()). So if you have code like so

names.findAll { it.firstName == "Peter" || it.firstName == "Alan" }

you can make it a bit more Groovy by using in:

names.findAll { it.firstName in [ "Peter", "Alan"] }

Wonderful stuff. One last note: beware using it with BigDecimal floating point numbers because it may not work the way you expect:

def numbers = [ 1.0, 2.00, 4.567, 3.123 ]
assert 1.0 in numbers
assert 1.000 in numbers

The second assertion fails because 1.0 != 1.000 according to BigDecimal.equals(). Of course, that may change in a future version of Groovy, so it’s always worth checking out in the Groovy console or shell first.

Have fun with your new friend!

A couple of notes about Groovy syntax

I’ve seen a fair bit of Groovy code and there are a couple of common syntax usages that I think could do with some clarification. First off is use of the def keyword.

As we all know, if you want to declare a variable in Groovy with no or dynamic type, you use def. But there are some subtleties to this seemingly simple rule. If you are completely new to Groovy, then you might interpret that rule to mean that an untyped method signature would look like

private def someMethod(def arg1, def arg2) {
    ...
}

Groovy does in fact accept the above, but it’s more verbose that it needs to be. Method arguments need no type:

private def someMethod(arg1, arg2) {
    ...
}

and if the method has a scope (private, protected, etc), then you don’t need def for the return type:

private someMethod(arg1, arg2) {
    ...
}

However, if there is no explicit scope, the return type is required:

def someMethod(arg1, arg2) {
    ...
}

This behaviour extends to fields and local variables as well. You do not need def if a variable is declared with a scope, the static keyword, or final. So all the following are valid field declarations:

private static final name
protected age
static count
final id
static final PATTERN

I guess some people like to use def to keep the syntax consistent with the typed version, but it just adds clutter to my eyes.

The second usage I want to look at concerns GStrings. Many a time I have seen code like this:

println "${name}"

where name is some variable. Notice that there is no other text in the string, it’s just a single variable in a GString. Why? I think there might be two reasons: habit and as a replacement for toString().

Once you get used to using GStrings, they become a habit. I have even found myself doing the above, even when the variable in question is quite definitely a string already! That just causes confusion for anyone reading the code, so I typically get rid of the quotes and braces as soon as I notice. I recommend you do the same, particularly as it may be you reading the code 6 months down the line.

As a replacement for toString(), the GString syntax has the benefit of brevity. Some words of caution though. First, you may not need it. Take a look at the previous example: println() automatically calls toString() on it’s argument, so there’s no need to do it yourself. Second, if the variable or argument is definitely going to be a string, then the GString syntax just obfuscates the code. Last, but definitely not least, you end up with a GString instance.

Most of the time, GStrings and strings can be used interchangeably. In fact, Groovy goes out of it’s way to make sure this is the case, so you don’t have to worry about it. But if you ever do an instanceof check that compares a GString to a string, you’ll get false as a result. It’s not common, but it can happen. We’ve hit the problem a few times in the Grails code.

Before I finish, a quick note on GStrings. Groovy automatically coerces (or converts) some types to others. One such coercion is from GString to String. However, this automatic coercion can only occur if Groovy knows that the target type is a string. For example, if a method argument or a variable is declared explicitly as String. When you use dynamic types, it’s up to you to handle GStrings and normal strings correctly.

Now you know what’s possible, you can make an informed choice as to the style you use.

London GGUG in the new year

After a successful Groovy & Grails eXchange run by SkillsMatter last week, it seems that there is plenty of interest in keeping the London GGUG going on a regular basis. Several ideas were floated then, so I thought I’d bring them up here and elicit feedback:

1. Two or three standard talks of 30-45mins each about any subject. Topics I would like to see covered include (in no particular order):
   • Gaelyk
   • Griffon
   • Real life Grails on Google App Engine
   • Real life Grails on Cloud Foundry
   • Grails deployment and data migration
   • GPars and/or static Groovy
   • Writing AST transformations
2. 6 * 10-15min slots on any topic, first come, first served
3. Plugin-fest – anyone can get up and present for 5-15 mins on their favourite plugins (no agenda)
4. Crowd-programming on an app, plugin, Grails issues, or anything else

If anyone has other ideas on session types or topics, then please let me know. I’m hoping that I can organise one with SkillsMatter sometime in mid- to late-January, so place your vote on what type of session you’d like! I’m currently thinking of a session with 5 or 6 10-15 min talks on what people are using Grails for, with plenty of time for questions.

I hope to see you in the new year!