If you haven’t played with the Cache plugin before, here’s the skinny. Imagine you have a controller or service that performs a couple of  expensive operations on some shared dataset (you are going to refactor it into a service, right? . Here’s our skeleton placeholder:

package hubbub

import grails.plugin.cache.CacheEvict
import grails.plugin.cache.Cacheable
import java.util.concurrent.atomic.AtomicInteger

class CounterController {

    static defaultAction = "invalidatingMethod"

    static AtomicInteger counter = new AtomicInteger()

    @Cacheable("myCache")
    def expensiveMethod1() {

    	// imagine the massive query from hell
    	render "The latest value is ${counter.incrementAndGet()}"

    }

    @Cacheable("myOtherCache")
    def expensiveMethod2() {

    	// imagine another massive query from hell
    	render "The latest value is ${counter.incrementAndGet()}"

    }

    @CacheEvict(value=['myCache','myOtherCache'], allEntries=true)
    def invalidatingMethod() {
    	// Something that would invalidate the cache... like a DB update
    	render "The caches have been cleared"
    }
}

So our expensiveMethod1() and expensiveMethod2() have been marked @Cacheable. This means that Grails will intercept the calls, to these method, catch the return values and squirrel them off to the Cacheing infrastructure (in memory by default, so it will be reset on JVM restart).  Next time you call the method, Grails will returned the cached value (which saves you all that processing time).

In the scenario above, I’m using two different caches with two different names. I’m then using the annotation on invalidatingMethod() to clear an array of cache names in one hit! I’m not sure that’s covered in the current docs, I had to go hunting through the source. But at least it’s now google-able!

So, I’ve made my calls to each of my cached methods and confirmed they are returning cached values, for instance. :

1. http://localhost:8080/hubbub/counter/expensiveMethod1 » The latest value is 1
2. http://localhost:8080/hubbub/counter/expensiveMethod2 » The latest value is 2
3. http://localhost:8080/hubbub/counter/expensiveMethod1 » The latest value is 1
4. http://localhost:8080/hubbub/counter/expensiveMethod2 » The latest value is 2

Imaging I then made method calls my invalidating method, and you can see how the cache is operating on the data (or copy and paste and try it at home for even more XP)

1. http://localhost:8080/hubbub/counter/invalidatingMethod » The caches have been cleared
2. http://localhost:8080/hubbub/counter/expensiveMethod1 » The latest value is 3
3. http://localhost:8080/hubbub/counter/expensiveMethod2 » The latest value is 4
4. http://localhost:8080/hubbub/counter/expensiveMethod1 » The latest value is 3
5. http://localhost:8080/hubbub/counter/expensiveMethod2 » The latest value is 4

So the first invocation to the cached method after the caches have been cleared repopulates the cache with the new value. Awesome!

This new lightweight caching is a very cool feature of Grails 2.x line and you should definitely checkout the docs to see way you can configure those caches to be persistent, overflow, etc.

Happy Caching!

(Regular shameless plugin: If you want to find out more about what’s new in Grails 2.x, make sure you checkout the MEAP of Grails in Action 2 which is now on the Manning Site and for which we’ll soon be releasing the plugins chapter which covers Caching and other goodness).

So I was originally thinking of doing it all by hand in StaX using the XmlEventReader. After all, it’s build into modern Java platforms and gives you the freedom to do what you want. But there’s the small matter of writing your own state-tracking using Stacks or whatnot.

The other night at  our local Canberra JUG we were talking about how great Commons Digester was for this stuff back in the day. Well, I figured I revisit it and it turns out Digester3 was just the ticket for my little problem. If you’re interested in a tutorial, there’s a great one here.

But one FAQ remained. I needed to slurp out a few of the nested nodes in the xml as an xml string. The docs are pretty lean on such things, but it turns out there’s plenty of magic in the framework to help you out.

First, you’ll need to take advantage of the NoteCreateRule object which invoke your parsed object with an xml Element of the matched node:

 forPattern("manual/part/chapter/section/controlsTitle/block/controls/block/content").
    addRule(new NodeCreateRule()).then().setNext("setDescriptionFromXml");

Once you have a handle to that bad boy, it’s just a matter of adding a method to your target bean object that takes such a beast. A little help from Stack Overflow, and I can turn that xml into a String and strip out the tags for my own nefarious reasons…

  // http://stackoverflow.com/questions/1219596/how-to-i-output-org-w3c-dom-element-to-string-format-in-java
    public void setDescriptionFromXml(Element element) throws Exception {
        TransformerFactory transFactory = TransformerFactory.newInstance();
        Transformer transformer = transFactory.newTransformer();
        StringWriter buffer = new StringWriter();
        transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
        transformer.transform(new DOMSource(element), new StreamResult(buffer));
        String str = buffer.toString().replaceAll("\\<.*?\\>", "").trim(); // strip all XML tags
        setDescription(str);

    }

Anyways, I thought it was worth writing up the process in case you ever need to use Commons Digester to get at the raw xml of a portion of your parse tree.

Grails 2.0 introduced this cute little tag called <g:external> for that very common case of linking to CSS, JavaScript and favicons. Back in the old days, you used to use some kind of “resource” link, perhaps as a method call for brevity (or in the even older days you might have used a createLinkTo tag, but that’s showing my age):

<link rel="stylesheet" href="${resource(dir:'css',file:'hubbub.css')}" />

But these days, <g:external> is the tag for you! It will sense whether you’re linking to css, javascript, some kind of image (for a favicon), or that crazy Apple-icon-specific-thing, and generate the appropriate <link> tag for you. Behold the magic of external:

<g:external dir='css' file='hubbub.css'/>

This will generate the full <link> text you need, including the appropriate context for your app:

<link href="/hubbub/static/css/hubbub.css" type="text/css" rel="stylesheet" 
       media="screen, projector" dir="css" file="hubbub.css" 
       contextPath="/hubbub"/>

But the truly wonderful part of the little gem of a tag (as you’ll notice in the generated code above) is that it is resources-aware. That means that you get cache-able goodness of the resources plugin, along with all the static-mapping magic that exposes to you.

There is also a uri version of the tag has a little less ceremony where you link context relevant content and it will be scooped up and re-written, however it didn’t seem to happen for me on 2.2.0…

<g:external uri='/css/hubbub.css'/>

No time to waste! Go forth and externalise! Just perfect for your next CSS, JS and Favicon <link> usage!

(Oh, PS. if you’re after a Grails 2.0 book to get started, shameless plugin for Grails in Action 2.0 which is in MEAP.)

So, today’s challenge: finding a way to tell if a given File has completed copying to the upload directory or is still in the process of being copied. A colleague pointed me at nio, and we threw together something to get the job done (we already knew that File.exists() and File.canRead(), so your effort may need to be a little more robust than this one, but this will get you started):

   private boolean hasFinishedCopying(File file) {
     
        FileInputStream fis = null;
        FileLock lock = null;
        try {
            fis = new FileInputStream(file);
            FileChannel fc = fis.getChannel();
            lock = fc.tryLock(0L, Long.MAX_VALUE, true);
        } catch (IOException ioe) {
            return false;
        } finally {
            if (fis != null) {
                try {
                    fis.close();
                } catch (IOException ioe) {
                    // give up...
                }
            }
        }
        return lock != null;
    }

The magic you need to be aware of is that third boolean argument to tryLock() on a FileChannel. That says “I want to try to get a shared lock on this file for reading and I under someone else might be writing at the moment”. That’s just my scenario! (And without that shared switch you’ll end up with a NonWritableChannelException).

There’s probably a better way of accomplishing this task, but I thought I would at least blog up one option that we’ve tested to work, so that I can Google this later (since I am sure this is a problem I faced before!).

Happy locking!

Just for putting the cream on top, the brief smoke test I did will JMeter showed that it is likely to perform with ample headroom under my anticipated load.

The one snag I did have was getting it integrated into JBoss Developer Studio (basically a customised Eclipse). Even though there are great instructions on the TomEE site, I was a bit lost as to exactly which windows that the text was describing.

So here’s the skinny..

Open up the Server window and add a new Tomcat 7 server, giving it the path to your Tom EE installation. Follow the wizard and live the default lifestyle.

After that you’ll get a Servers twisty that appears under project in the Project Explorer window (normally the big window on the far left in the default implementation). When you fold out that server, you’ll see that it’s only got the tomcat config files (no tomee.xml or any of the other tomee specific configs). Without those you’ll get weird errors about mapping your JPA providers to HSQLDB or My Data Source or some other bizarre default.

So what you’ll need to do is right click on the “Tomcat v7.0 Server” entry above, and select /Import…/General/File System/ and select the logging.properties, system.properites and tomee.xml entries. With those inplace, your JBoss Develop Studio can happily spark up TomEE right inside the IDE.

Once you’ve got all that infrastructure in place, click on your Servers tab (not in the Project Explorer view, but in the actual Servers view ala /Window/Show View/Servers) . You’ll now be able to right click on your Tomcat Server and click Start…

Enjoy your rapid turnaround cycles!

The only snag I’ve hit so far is that I haven’t been able to get in working with SQL Server jTDS data sources using Integrated Security. It’s fine when I specify a username/password, but not happy if I leave those blank. But that’s for another day…

• Grails 2.0 Deep Dive. Did ok on this one. I’ve spend most of the year working full time on a big commercial Grails application, and this year I definitely levelled up my commercial development. In particular, I’ve done a lot of work with evolving schemas in a deployed commercial product using the db migrations plugin, written a truckload of Spock tests, and applied some tricky corner cases in Spring Security Active Directory integration. Also did lots with the new Resources plugin, and had plenty of fun with Elastic Search.  Somewhere in there I wrote the first half of Grails in Action 2nd Ed, and am looking forward to knocking off my remaining chapters early this year. In terms of going deeper, have really enjoyed reading Burt’s hardcore book, and Jeff and Graeme’s new book should be out soon too..
• GUI Applications. I had a couple of Swing client projects slated for this year, but only one of them happened. Turns out Swing was just as complex as I remembered it . To be fair, if Java SE had the Events stuff from CDI built in, I think I’d find things a lot more attractive.
• Integration Testing. Did some tinkering with Geb this year, but didn’t really make it to the place where I wanted to get to. Need to circle back on this one this year.
• JBoss. Yes indeed. Really connected with our local Aussie JBoss folk this year, and they are an awesome bunch. Really strong hacker culture in that org, right down to the grass roots. Going to be doing a lot more with them in 2013 and really looking forward to connecting up with a few more of the players in that space. And to play with Arquillian in anger.
• MongoDb. Didn’t happen this year. I’m really excited about the schemaless model of Mongo, just didn’t come across a project this year that would have had significant benefit from it. Might be time to cook up a hobby project in 2013, just to get dirtier hands.

So, overall, I learned a ton this year, but didn’t really end up targeting the area I thought I would. All part of the journey, eh?

In the next post, I’ll outline what’s on my learning list for 2013. But I’m still stewing on what I’m going to commit to… but I think the theme will all be around “lean” and stripping things right back to basics.

Hope you all have an Amazing 2013 filling the world with awesome software!

Glen.

Update: BalusC has done an amazing post about Shiro/JSF. Head over there instead!

I know very little about JSF2, and even less about Apache Shiro, but both have been on the learning list for a while, so this blog will document up how to get them working together from beginner’s eyes. Be gentle. I’ve deployed the sample to JBoss OpenShift while I’m experimenting, if you’d like to take it for a spin.

First, you’ll need a basic shiro.ini file which you can dump in your standard /WEB-INF directory. Here’s a scratcher to get you started which will protect our “protected.xhtml” file and redirect the user to the “login.xhtml” file.

[main]
authc.loginUrl = /login.xhtml
authc = org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter
securityManager.rememberMeManager.cookie.name = demoRememberMe

[users]
admin = secret

[roles]
admin = *

[urls]
/index.xhtml = anon
/protected.xhtml = authc

Couple of bits of magic about. The most important one is that you need to be using the PassThruAuthenticatorFilter when you’re working with JSF (which I found out about here). JSF will do magic stuff with your html INPUT element names, so you won’t be able to use the standard Shiro form filters that know about username, password, rememberMe form elements. I’ve also customised the “rememberMe” cookie name in the above, just because I was keen to explore how you do that!

With our config in place, next stop is to make the changes in web.xml to ensure that the Shiro filter fires. This is all standard Shiro stuff, no special JSF interplace required:

<filter>
        <filter-name>ShiroFilter</filter-name>
        <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>ShiroFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
        <dispatcher>ERROR</dispatcher>
    </filter-mapping>
    <listener>
        <listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class>
    </listener>

With all our web.xml filters in place, the next step is to write up the basic JSF login form. Here’s my minimalist version of login.xhtml:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core">
<h:head>
	<title>Login Page</title>
</h:head>
<h:body>

	<h:form>
		<h:messages />

		<h2>Login Page</h2>
		<p>You can use "admin" and "secret" to login.</p>
		<h:panelGrid columns="3">

			<h:outputLabel for="username" value="User Name:" />
			<h:inputText id="username" value="#{loginController.username}"
				required="true" label="Username" />
			<h:message for="username" />

			<h:outputLabel for="password" value="Password:" />
			<h:inputSecret id="password" value="#{loginController.password}"
				label="Password" />
			<h:message for="password" />

			<h:outputLabel for="rememberMe" value="Remember Me:" />
			<h:selectBooleanCheckbox id="rememberMe"
				value="#{loginController.rememberMe}" />

			<h:commandButton action="#{loginController.authenticate()}"
				value="Login" />

		</h:panelGrid>
	</h:form>
</h:body>
</html>

Nothing too special there. We have fields for our username, password and rememberMe, just need to wire it up to our loginController, and life will be good. Here’s what it looks like so far:

Next, we’ll need to whip up our loginController JSF backing bean with elements for our username, password, rememberMe, and, of course, logic to do the actual authentication. Here’s my rough one to get you started:

package au.com.bytecode.controller;

import java.util.logging.Logger;
import javax.enterprise.inject.Model;
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import org.apache.shiro.SecurityUtils;
import org.apache.shiro.authc.AuthenticationException;
import org.apache.shiro.authc.UsernamePasswordToken;
import org.apache.shiro.subject.Subject;

/**
 * Simple JSF Controller demonstrating Shiro login/logout process.
 * 
 * @author Glen Smith
 */
@Model
public class LoginController {

	String username;
	String password;
	boolean rememberMe = false;

	private static final Logger log = Logger.getLogger(LoginController.class
			.getName());

	public String authenticate() {

		// Example using most common scenario of username/password pair:
		UsernamePasswordToken token = new UsernamePasswordToken(username,
				password);

		// "Remember Me" built-in:
		token.setRememberMe(rememberMe);

		Subject currentUser = SecurityUtils.getSubject();

		log.info("Submitting login with username of " + username
				+ " and password of " + password);

		try {
			currentUser.login(token);
		} catch (AuthenticationException e) {
			// Could catch a subclass of AuthenticationException if you like
			log.warning(e.getMessage());
			FacesContext.getCurrentInstance().addMessage(
					null,
					new FacesMessage("Login Failed: " + e.getMessage(), e
							.toString()));
			return "/login";
		}
		return "protected?faces-redirect=true";

	}

	public String logout() {

		Subject currentUser = SecurityUtils.getSubject();
		try {
			currentUser.logout();
		} catch (Exception e) {
			log.warning(e.toString());
		}
		return "index";
	}

	public String getUsername() {
		return username;
	}

	public void setUsername(String username) {
		this.username = username;
	}

	public String getPassword() {
		return password;
	}

	public void setPassword(String password) {
		this.password = password;
	}

	public boolean getRememberMe() {
		return rememberMe;
	}

	public void setRememberMe(boolean rememberMe) {
		this.rememberMe = rememberMe;
	}

}

You probably don’t want to really log usernames and passwords to the console , but it’s helpful when you’re learning how things are hanging together.  The core part of the deal is the authenticate() method. In here, you’re doing a Shiro authenticate using the standard API hooks.

I’ve also put together a logout() method above too.  Helpful when testing your cookies out . I call this from the protected.xhtml page via a commandButton to force the logout:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html">
    <h:head>
        <title>Secret Page</title>
    </h:head>
    <h:body>
        This is a super secret page.
        <h:form>
            <h:commandButton action="${loginController.logout()}" value="Logout"/>
        </h:form>
    </h:body>
</html>

So there you have it! Shiro integration with JSF turns out to be pretty straightfoward once you’re aware of that PassThruAuthenticator trick! Next on my explore list is to get Shiro DB realm integration happening with JPA2! Should be some interesting CDI challenges there…

Once again, if you’d like to take it for a spin, I’ve deployed it to the JBoss cloud to see what that experience was like (very straightforward so far, topic for another post). Also good to know that Shiro runs fine on cloud services!

Edit: Even better if you use WebUtils to remember the page that was being intercepted when the user was sent to login as discussed here.

Something like this would do the trick….

log.info("Submitting login with username of " + username
		+ " and password of " + password);

try {
	currentUser.login(token);
	FacesContext fc = FacesContext.getCurrentInstance();
	fc.responseComplete();
	HttpServletRequest request = (HttpServletRequest) fc.getExternalContext().getRequest();
	HttpServletResponse response = (HttpServletResponse) fc.getExternalContext().getResponse();
	String fallbackUrl = "/index.xhtml";
	WebUtils.redirectToSavedRequest(request, response, fallbackUrl);
	return null;
} catch (Exception e) {
	// Could catch a subclass of AuthenticationException if you like
	log.warning(e.getMessage());
	FacesContext.getCurrentInstance().addMessage(
			null,
			new FacesMessage("Login Failed: " + e.getMessage(), e
					.toString()));
	return "/login";
}

Happy JSF/Shiro-ing!

These days I’m using a Galaxy Nexus mobile phone which I have flashed to the latest Factory Image (worth doing if you’re still stuck on 4.0.x – totally safe these days and completely legit). The phone is great, but I’ve been stuck with a day and a half of battery life, which just isn’t enough for my liking.

If I have a look at the built in battery stats, I’m seeing something like:

Well, a day and a half is pretty cool. But what exactly is “Google Services” and why is it taking so much of my battery? So I set out on a journey to find exactly where all that battery was going. After a bit of googling, a lot of people were recommending blowing $3 on Better Battery Stats to see exactly where all that battery was going.

Better Battery Stats will tell let you in on Partial Wakelocks (apps that are stopping your phone going into deep sleep and saving tons of battery). Best of all, it operates passively off standard phone events, so gathering stats costs you no battery life at all. It will only start gathering after your first charge, but since that was happening every day, it was no problem

So, first look at where things are going:

Ok, so first off my wakelocks are being interruped by the phone app itself. Well, 40 mins of talk time isn’t much for a day or so, but there’s not much I can do about that!  The two audio settings are related to Music/Podcasting on the way to work (I love Podkicker Pro so much – go spend another $3 on that while you’re in the store).

But look at the “Count” setting on that NetworkLocationLocator instances! My phone was waking up thousands of times to just let Google know my current location. The first one of those looks “maps related”, and it seems I had Maps running and set to “always update my location” even when I wasn’t using Maps, so that was the first to go.

The second one seems to be related to Google Now (which is also a constant and massive location updater, so that was next on the list). I don’t actually use it, so I just turned it off!

Ok, another day passes, and I’ve got a few more hours, but not the massive win I was after. Next round of tuning.

GTALK_ASYNC_CONN is my next “Google Services” worth having a look at. Looks like Google just can’t handle the fact that something isn’t letting them know where I am all the time! So next I just disabled Google Talk (since I don’t use it anyway). Probably just logging out would be enough, but I was in aggressive tuning mode, so I figured I’d go for the gold.

Bingo! Now I was cooking. Hit the 3 day mark no problems with a similar pattern of phone use:

At this point, my biggest wakelock action was just standard Gmail sync and other actual phone services! Woot! For completeness, this was a picture of my current wakelocks:

Preview

Biggest burn is from actual phone calls, listening to Podcasts and download mail! All things that are core to my life that I’m happy to live with. After that I started looking into Kernel wakelocks (wifi, nfc,etc), and realised that leaving Wifi on all the time was better than turning it off overnight (since 3G was probably more expensive to run).

Anyways, I have my 3 days using the services I like, so I’m pretty excited.

Go forth and tune!

The audience were all Java and Dotnet developers, most with some revision control experience, some with real-world Git experience. I developed the course with a more experienced Git developer, who was supporting me on the day with deep-dives and examples (which was awesome – love the dual trainer thing, good for the class too).

Let’s get Meta. So what did I learn about how people learn Git?

• We covered about 30 commands during the course of a 7 hour day (zoom in on the training board picture that we were walking through above), and I was surprised that I use nearly all of those commands every day (so the Git feature set is much broader than your typical SVN/CVS flow).
• Git Internals are so “wafer-thin-below-the-surface” that you might as well teach how Git works from the start. Next time I’ll use a desk workflow with paper cards to discuss how DAGs hang together after the first module of playing. I like what this guy did, and I would like to try that with index cards.
• Teaching people the Reflog early really helps them to get that things are very safe with Git, much safer than with anything else they’ve used – and that a commit really is immutable (regardless of what they hear about rewriting history/commits/etc). That knowledge actually gives you confidence to, well, rewrite history.
• Remoting is really where people started to fall off the wagon. They could live with a staging area, but the idea of local and remote repos really needed a lot more exercises and a lot more experimenting. Pull/Fetch and diffing from master..origin/master… wat? Well.. Next round of courseware will spend more time on that. And more exercises.
• Learning how Reset really works also requires a really solid mental model of the Git DAG. Next time I will spend more time on paper away from the terminal working through all this on index cards before we get lost in the weeds.
• People were more comfortable with rebasing than I thought. In fact, interactive rebasing was totally fine, and rebasing master to branch seemed to have a pretty clear mental model for most people.
• We taught everything through Git Bash, and I probably would offer Posh Git as a good albeit slow Powershell alternative for the guys who were new to Unix.
• Giving people concrete ideas on team Git workflows (such as GitHub Flow) is really helpful when you have so much flexibility. Need to workshop that one a bit hard for next time.

One of them relates to testing more complex UrlMapping setups. For instance, here are a couple of interesting examples to get you thinking:

class UrlMappings {

    static mappings = {
         // other mappings here...

        "/timeline/chuck_norris" {
            controller = "post"
            action = "timeline"
            id = "chuck_norris"
        }

        "/users/$id" {
            controller = "post"
            action = "timeline"
        }

    }
}

So we have two mappings in place here. Both map to controller and action, with one setting a static id of “chuck_norris” and the other parsing the $id off the url. In both cases we end up inside the Post controller and fire off the timeline action.

To test this bad boy, we want to test the mapping to action and controller, but we also want to test the params that we have either (a) parsed out of the url; or (b) set within the mapping block.

The magic you need to know is that assertForwardUrlMapping takes an optional closure as the final parameter. Inside that closure, you assign the values to expect to receive, and UrlMappingsUnitTestMixin will do the heavy work of comparison for you. Enter the Spec….

import com.grailsinaction.PostController
import grails.test.mixin.Mock
import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(UrlMappings)
@Mock(PostController)
class UrlMappingsSpec extends Specification {

    def "Ensure basic mapping operations for user permalink"() {

        expect:
        assertForwardUrlMapping(url, controller: expectCtrl, action: expectAction) {
            id = expectId
        }

        where:
        url                     | expectCtrl| expectAction  | expectId
        '/users/glen'           | 'post'    | 'timeline'    | 'glen'
        '/timeline/chuck_norris'| 'post'    | 'timeline'    | 'chuck_norris'
    }

}

Just remember, the Closure takes a set of assignments (id = ‘abc’) not comparisons (id == ‘abc’) and you’re in business.

We have a truckload of tests like these in Grails In Action 2, so if you’re into this style of experimenting, you’re going to enjoy reading the samples.

Go forth and test your complex mappings!