LD.

Gr8Conf EU, now with more me

Tue, 03 Apr 2012 20:17:58 +1000

I’m excited to be presenting a GR8Conf EU this year. This will be my first time at GR8 Conf and I’m looking forward to meeting some of the Groovy community that I’ve not had the opportunity to meet before.

I’ll be presenting on Geb, as both an introduction for the uninitiated and to discuss the new features that have appeared in the last few months. It will be an interesting change to present this material to a crowd already comfortable with Groovy; quite different to my upcoming session at SeleniumConf.

Of course, I’ll also be there representing Gradleware and helping Peter give a 3 hour Gradle Bootcamp that will get anybody up and running with Gradle. I’ll also be doing another (new) Gradle session on releasing software. This will be a tutorial style presentation that will arm you with everything you need to build, test and release open source software to Maven Central with Gradle. There will also be a dive into the Spock and Geb builds to look at how they managing building and testing Grails plugins as part of their builds and automating their release.

Hope to see you there!

In response to Rob's post on functional testing.

Fri, 25 Nov 2011 00:49:00 +1100

Rob, a Geb committer and all around cool dude, recently posted some thoughts on function testing.

The following is what I intended to be a comment on Rob’s blog, but it became too long so I decided to post it here. You’ll notice that the language is a bit weird as in some places I am addressing Rob directly. It should make sense (no guarantees) if you pretend you are reading it as a comment on Rob’s blog.

This is not a flame war, though that would be fun. Rob’s a friend of mine and a respected colleague. This is just a discussion and exchange of ideas.

Without further ado, the comment…

I’ll try to be as objective as I can, but obviously as someone who is invested in Geb I come with a bit of a bias.

You seem to be mixing up several different issues, which is understandable as the post seems born out of frustration.

For my mind there are three discrete parts:

The development environment (the language/framework/constructs you use to express the test)
The execution environment
The debugging environment

They lines blur, but I think it’s helpful to think about each part separately. Geb itself only lives in the first arena strictly speaking. How it works in the execution and debugging environment are largely aspects of the associated tooling, with the exception of static diagnostic information.

So a couple of points:

“I agree that as much testing as possible should be done at as low a level as possible”

What’s usually missing from this sentiment is the why. Too many people take this stance because testing at a low level is easier. This, in isolation, is not the right way to think about it. The end goal is always working software, not easy tests. Easy tests work towards working software by making it more likely that tests will be created in the first place and maintained. They are low cost/low value. So for me, low level testing is fine until the accuracy compromist becomes too high. If it doesn’t create a lot of confidence that the system will work, either because it assumes to much or is not backed up by higher level tests, then the developer is fooling themselves. Passing tests is not the end goal, working software is.

It’s with that in mind that I usually say to people that we need to “suck it up” to a certain extent with functional tests. You should identify if there is value in having automated tests that verify the end to end behaviour of your system, get a feel for what that value is and act accordingly. Then you can make cost/benefit judgements on how much effort to put into functional testing. Avoiding it because it’s not as easy as unit testing while not taking the value into account is irresponsible, in my opinion. However, we definitely should harness the frustration and desire for simplicity to make it easier.

“Even assuming you can optimise so that the application is running and you can run the test from an IDE then Selenium has to start up a browser instance, queries execute, views need to render, etc”

Selenium doesn’t have to start up a browser instance, it’s possible to use an running browser instance. Also, on modern development machines we should be talking about seconds at most to run queries and render views etc.

As for the Grails specific issues, you’re going to face the slow application startup when working with Grails no matter what your development environment. In theory, there’s no difference between different development environments here, but the difference comes in in execution environments. However, it’s possible to create an execution environment for Geb tests (run in IDE against a running application) that is equivalent to the Selenium IDE experience.

“Geb’s output when a waitFor condition fails is just Condition did not pass in x seconds.”

This is indeed painful. Even with implicit power asserts it doesn’t get much better. Providing static diagnostic information for functional tests (i.e. non dynamic like an interactive debugging session) is one of the unsolved problems in this area. I’m not aware of any tool that has a good approach to this. With Geb our approach is to just dump the browser state, but that information is generally not rich enough. Hopefully someone comes up with a good solution.

“Selenese is by no means great in this regard (a humble Condition timed out isn’t much help) but at least you can step back with the Selenium IDE and watch the damn thing not working much more easily.”

I think much more easily is a stretch. You can do the same thing with a Geb/WebDriver test. The only difference being is that the test method is your smallest level of granularity for re-running a part of the test. That’s a clear advantage that Selenium IDE has; the ability to run a selected portion of the story at any granularity. It seems like this would break down for most stories though as they require context that needs to be run as well.

“The most productive I’ve ever been when writing functional tests has been when using Selenium IDE.”

(and the rest of this paragraph and the next)

There’s only one point you make here that can’t be replicated with Geb/WebDriver in an IDE: selecting a portion of the test at any granularity and just running that. Everything else is also possible in an IDE, and is the exact same process you would use to debug other code. These are all points on the execution/debugging environment not the development environment.

“Despite these significant failings writing tests in Selenium IDE is very effective. Maintaining a suite of such tests is another matter. Working on a long-running project the failings of Selenese tests start to increase logarithmically.”

This is the point for me. Experience has shown that the majority of the cost of a functional test suite comes in maintenance, not initial development. Therefore the sensible thing to do is to optimise for this first and development speed second. Maintenance should be foremost in the developer’s mind when developing functional test. The PageObject pattern and inline test data are the two best techniquest that I am aware of that help here.

“I’m convinced that the goal of writing tests in the same language as the application is a pretty vapid one. Working inside one’s comfort zone is all very well but too many times I’ve seen things tested using Selenium or Geb that would be better tested with a unit-level JavaScript test.”

It’s not necessarily about using the same language, it’s about integration and sharing data structures. Equating functional testing to black box testing is incorrect I think. I have no problem with stimulating the system as a user, but poking inside to verify internal state. To me, that’s more productive and accurate.

JavaScript unit tests aren’t a replacement for functional tests. You shouldn’t be using functional tests to unit test JavaScript, but having JavaScript unit tests doesn’t relieve you from having functional tests. It can mean you need less though. If a test doesn’t emulate what a user does (including the user environment) to a reasonable degree of accuracy it is not a functional test.

“As a Grails developer I’ve looked enviously at how fast tests run in Rails apps but that’s nothing compared to watching a couple of hundred Jasmine tests run in under a second.”

I think you’re comparing apples and oranges here. I’d have little faith in a system that only has JavaScript unit tests.

“I was at one time convinced that the ability to use loops and conditional statements in Groovy made it a more suitable testing language than Selenese but honestly, how often are such constructs really required for tests?”

In my experience, these constructs are more useful when modelling the concept with appropriate abstractions. As interaction with web pages becomes richer (gestures, dragging etc.), I think we’ll see it become more useful there. That is, one logical interaction may have looping/branching logic internally but we want to model it as one abstraction.

“Building Geb content definitions with deeply nested layers of Module types is time consuming & difficult.”

I agree. However, when you put the effort in and do this right you get maintainable tests plus a wealth of predefined abstractions to draw on in future tests. That is, high cost/high value. With my Geb hat on, I think we have the best story in this area in terms of provided constructs. What we lack is the shared knowledge and experience to deploy these constructs effectively. I think every tool that tries to do this has the same problem though. In a word, inexperience.

“I can’t help thinking the page object model approach is coming at the problem from the wrong angle. Instead of abstracting the UI shouldn’t we be abstracting the behaviour?”

I think you need both. You can’t do away with abstracting the UI.

Geb’s in a tight spot here in that it has no execution model. This makes it awkward to introduce behaviour abstractions as we’d have to wrestle the execution control away from the execution framework we are integrating with. Ultimately, this abstraction belongs in JUnit/Spock/whatever. Spock is missing this capability, and that’s a known problem.

“The most impressive Selenium extension I’ve seen is Steve Cresswell’s Natural Language Extensions that layers something like JBehave’s feature definition language on top of Selenese.”

Not being a Selenese expert, this seems like it would give you the the behaviour abstractions you desire but you’d have to either largely abandon UI abstraction or maintain that separately.

I’d love to see someone start a project adapting something like Fitnesse or some other natural language based tool to Geb. You’d get the same behaviour abstraction benefits, but get to use Geb’s page modelling to maintain the UI abstractions. Hopefully someone starts this.

As for cucumber, if you want natural language authoring I think it’s the choice. There are posts out there about people layering it on top of Geb.

I’m very skeptical of FuncUnit, but not well educated about it. It’s not clear to me how it fits into an automated build and it seems like it would have a very high mental context switching cost. You also give up on data structure sharing entirely.

That’s it.

So the take home for me is that we need to spend more effort on the execution and debugging environments for Geb. Perhaps this will be the focus of the 0.7.x series which will be starting soon.

Geb Modules and isDisplayed()

Thu, 16 Jun 2011 09:56:16 +1000

A question recently came up on the Geb user mailing list about checking to see if a module is displayed on a page. It turns out the concept of displayed could do with some exploration.

Say we have the following html…

<p class="a" style="display:none"/>
<p class="b"/>

The following assertions will pass…

def a = $("p.a")
def b = $("p.b")
def c = $("p.c")

assert a && !a.displayed
assert b && b.displayed
assert !c && !c.displayed

So isDisplayed() means that the navigator matches some content and the first thing that it has matched is actually visible on the page. $("p.c").displayed returns false because it doesn’t match anything.

Navigator objects implement the Groovy Truth, so those assertions could be written as…

assert a.size() != 0 && !a.displayed

Modules also implement the Groovy Truth using the same test, so…

class ParagraphA extends Module {
    static base = { $("p.a") }
}
class ParagraphB extends Module {
    static base = { $("p.b") }
}
class ParagraphB extends Module {
    static base = { $("p.c") }
}

Now assume we have moduleA, moduleB and moduleC vars that are instances of the corresponding modules, and we can write the following assertions…

assert moduleA && !moduleA.$().displayed
assert moduleB && moduleB.$().displayed
assert !moduleC && !moduleC.$().displayed

You can get the “base” of a module at anytime with «module».$(), just like you can do relative lookups (i.e. someModule.$(“p.d”))

Using Grails tags where you can't use Grails tags

Wed, 11 May 2011 11:40:00 +1000

Sometimes in a Grails app, you need to call a tag where you can’t call a tag. This is usually indicative of a bad design in your application so do use the following with caution, but should you absolutely need to… the following is how you can.

In this example, we are going to add the ability to call tags to a filter to workaround GRAILS-6814. We want to call the createLink tag.

Note that GRAILS-6814 has been resolved for Grails 1.4, so this workaround for redirects to a different domain only applies to Grails 1.3 and earlier

import org.codehaus.groovy.grails.web.pages.GroovyPage
import org.springframework.web.context.request.RequestContextHolder

class HttpsOnlyFilter {

    def gspTagLibraryLookup // need this autowired

    def filters = {
        redirectToHttps(controller: "*", action: "*") {
            before = {
                if (!request.secure && isSecurePage(controllerName, actionName)) {
                    def link = invokeTag("createLink", [
                        controller: controllerName, 
                        action: actionName, 
                        params: params, 
                        base: "https://secure.domain.com"
                    ]).toString()
                    response.status = 301
                    response.setHeader("Location", link)
                    false
                }
            }
        }
    }

    def invokeTag(name, attrs = [:], body = null) {
        def namespace
        def tagName

        if (name.contains(":")) {
            def split = name.split(":", 2)
            namespace = split[0]
            tagName = split[1]
        } else {
            namespace = GroovyPage.DEFAULT_NAMESPACE
            tagName = name
        }

        GroovyPage.captureTagOutput(gspTagLibraryLookup, namespace, tagName, attrs, body, RequestContextHolder.currentRequestAttributes())
    }

}

The invokeTag method takes; the name of a tag, a map of attributes, and an option body closure and returns a StreamCharBuffer (so if you want the content as a String you new to toString() the return). Inside the body closure, you can write to the out stream just like in a tag implementation.

If the tag name given to invokeTag() doesn’t include a namespace, the default g namespace is used. To invoke a tag in a different namespace, you can use…

invokeTag("someNamespace:someTag", [param1: 1])

Remember, requiring tags outside of the view layer can be indicative of a design problem so do think long and hard about whether you really need to before using the above. Also, the above will only work in a request environment so if you try to use the above on a background thread were a fake request environment hasn’t been established it will blow up due to RequestContextHolder.currentRequestAttributes() returning null. If you need to setup a fake request environment, you can use GrailsWebUtil.bindMockWebRequest() to do so.

Always developing Grails apps with https and testing against the WAR

Fri, 06 May 2011 13:54:43 +1000

In response to a number of bugs creeping through to production due to classpath differences and ssl issues, I went about setting up my culprit grails app to always functionally test as a war and with https in both development and testing. Here’s how to do it.

It turns out that there are two bugs/issues with the current grails tomcat plugin that get in the way of this objective, so you’ll have to install the 1.3.7.1 version of the tomcat plugin which fixes GRAILS-6688 and GRAILS-7488 for Grails 1.3.x (these issues will be fixed for Grails 1.4).

Always support https

This is quite simple, but perhaps a little tricky to work out. Simply put the following in your scripts/_Events.groovy…

eventParseArgumentsEnd = {
    argsMap.https = true
}

That’s the only suitable hook that I have found that can be used to force https to be used all the time (i.e. run-app and test-app). It’s a little heavy, but I’m yet to find a situation where it causes an issue.

Always functionally testing with a WAR

Again, this is simple. The following goes in scripts/_Events.groovy…

eventAllTestsStart = {
    testOptions.war = true
}

This is equivalent to always passing the -war argument to test-app.

Functional tests and SSL (trust)

Depending on how you are functionally testing (and you know you should be using Geb + Spock) you may have issues with the certificate that Grails will generate for you to serve https. Namely, you might need to go and configure trust settings in all of your functional test browsers etc. If you have multiple CI builds then you are going to have to do this for a lot of certs. Even worse, the cert that Grails generates is stored in the work dir so can be wiped out at any time.

You can minimise this pain by generating your own cert and having Grails use that when serving https instead of creating one on demand. To do this, you need the following two settings in BuildConfig.groovy…

grails.tomcat.keystorePath = "${basedir}/grails-app/conf/httpsKeystore"
grails.tomcat.keystorePassword = "secret"

You of course need to create this keystore with a cert in it, which you can do (in grails-app/conf) via…

keytool -genkey -alias localhost -dname CN=localhost,OU=Test,O=Test,C=US -keyalg RSA -validity 365 -storepass key -keystore httpsKeystore -storepass secret -keypass secret

You now only need to make sure the browser trusts this cert.

Why bother?

In my case, we were hitting some dependency issues that were due to the development and production classpaths being different so running functional tests against a war minimises this risk because the app is then run in a separate JVM without the Grails build time classpath, making it more production like.

The application that we were having problems with uses mixed http and https and is also reasonably AJAX heavy. Several issues had crept through with AJAX requests being made on secure pages to non secure pages (which will blow up due to the browser not being willing to compromise security by making the unsecure request).

These two relatively simple steps get you closer to a production environment if you don’t have the resourcing, manpower, will etc. to setup an elaborate QA environment for automated testing.

Decorating Constructors with Groovy

Fri, 04 Mar 2011 15:54:20 +1100

I recently put out a new plugin for Grails that brings something like view models to Grails applications. An interesting feature of this plugin is that it supports direct object instantiation with implicit autowiring. You might think that Grails already support this, but it doesn’t. Currently, you can directly instantiate domain objects and get autowiring but you can’t write a constructor and use it here.

Groovy has had the ability to fiddle with a class’s constructors via EMC for a while.

class Thing {
    def i
    Thing() { i = 1 }
}

assert new Thing().i == 1
Thing.metaClass.constructor = { -> i = 2 }
assert new Thing().i == 2

Trying to augment existing constructors is a bit trickier though. Using the standard EMC API of setting a constructor property on the meta class, there is no way to access the constructor that is being replaced. To do this you have to dig a bit deeper.

For the view models plugin I needed to invoke the real constructor, then do some stuff to the new instance. My solution revolves around the registerInstanceMethod(groovy.lang.MetaMethod method) method of ExpandoMetaClass. After some digging through Groovy, I found that the technique above of setting a constructor property on the meta class boils down to just attaching an instance MetaMethod with a method name of <init> which is the name Groovy uses for constructors. So what we can do is subclass groovy.lang.MetaMethod to get our custom behaviour, which looks like this…

package grails.plugin.viewmodels.constructor;

import java.lang.InstantiationException;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

import groovy.lang.MetaMethod;
import org.codehaus.groovy.reflection.CachedClass;
import org.codehaus.groovy.reflection.ReflectionCache;

public class DecoratingMetaConstructor<T> extends MetaMethod {

    final private Constructor<T> constructor;
    final private ConstructionDecorator<T> decorator;

    public DecoratingMetaConstructor(Constructor<T> constructor, ConstructionDecorator<T> decorator) {
        super(decorator.getSignature(constructor));

        this.constructor = constructor;
        this.decorator = decorator;
    }

    public Constructor<T> getConstructor() {
        return constructor;
    }

    public int getModifiers() {
        return constructor.getModifiers();
    }

    public String getName() {
        return "<init>";
    }

    public Class<T> getReturnType() {
        return constructor.getDeclaringClass();
    }

    public CachedClass getDeclaringClass() {
        return ReflectionCache.getCachedClass(constructor.getDeclaringClass());
    }

    public Object invoke(Object object, Object[] arguments) {
        Object[] transformedArgs = decorator.transformArgs(arguments);
        T instance = instantiate(transformedArgs);
        decorator.decorate(instance, arguments, transformedArgs);
        return instance;
    }

    protected T instantiate(Object[] arguments) {
        try {
            return decorator.transformConstructor(constructor).newInstance(arguments);
        } catch (InstantiationException e) {
            throw new RuntimeException("Failed to invoke constructor " + constructor + " with args: " + arguments, e);
        } catch (IllegalAccessException e) {
            throw new RuntimeException("Failed to invoke constructor " + constructor + " with args: " + arguments, e);
        } catch (InvocationTargetException e) {
            throw new RuntimeException("Failed to invoke constructor " + constructor + " with args: " + arguments, e);
        }
    }

}

A lot of that is just satisfying the MetaMethod methods. What’s of interest to us is that we take a constructor object, and a decorator which is an interface that we provide…

package grails.plugin.viewmodels.constructor;

import java.lang.reflect.Constructor;

public interface ConstructionDecorator<T> {

    public Object[] transformArgs(Object[] args);

    public void decorate(T instance, Object[] originalArgs, Object[] transformedArgs);

    public Class<?>[] getSignature(Constructor<T> constructor);

    public Constructor<T> transformConstructor(Constructor<T> constructor);
}

The decorator can supply a different set of args for the actual Constructor to those that were given to the invocation, supply a different Constructor instance to use at instantiation time and/or do something with the instance after it has been created.

We can use this mechanism to write a construction decorator that performs autowiring…

package grails.plugin.viewmodels.constructor;

import java.lang.reflect.Constructor;
import org.springframework.context.ApplicationContext;

public class AutowiringConstructionDecorator<T> extends ConstructionDecoratorSupport<T> {

    final private Autowirer autowirer;

    public AutowiringConstructionDecorator(ApplicationContext applicationContext) {
        this(new Autowirer(applicationContext));
    }

    public AutowiringConstructionDecorator(Autowirer autowirer) {
        this.autowirer = autowirer;
    }

    public void decorate(T instance, Object[] givenArgs, Object[] transformedArgs) {
        autowirer.autowire(instance);
    }

}

The Autowirer takes care of the actual autowiring details, which aren’t of much interest here (see the class here if you want).

So we can now take a class, and make all of it’s constructors implicitly perform autowiring by doing something like this…

def autowiringDecorator = new AutowiringConstructionDecorator(grailsApplication.mainContext)

for (constructor in MyThing.constructors) {
    MyThing.metaClass.registerInstanceMethod(new DecoratingMetaConstructor(constructor, autowiringDecorator))
}

Interestingly, I was able to use the same decoration mechanism to enable hot reloading support by obtaining the newest version of the constructor from the class loader in the Grails application that has the newest version of the class…

package grails.plugin.viewmodels.constructor;

import java.lang.reflect.Constructor;

class ReloadCapableConstructionDecorator<T> extends ConstructionDecoratorSupport<T> {

    private final ClassLoader classLoader;

    public ReloadCapableConstructionDecorator(ClassLoader classLoader) {
        this.classLoader = classLoader;
    }

    public Constructor<T> transformConstructor(Constructor<T> constructor) {
        try {
            Class<T> originalClassVersion = constructor.getDeclaringClass();
            Class<T> newestClassVersion = (Class<T>)classLoader.loadClass(originalClassVersion.getName());

            return newestClassVersion.getConstructor(constructor.getParameterTypes());
        } catch (NoSuchMethodException e) {
            return constructor;
        } catch (ClassNotFoundException e) {
            return constructor;
        }
    }

}

The details of why this is needed isn’t worth going into now, what’s important is the fact that you could do some rather interesting stuff here.

If you find you have the need to decorate existing constructors as opposed to completely replacing them, it’s probably worth taking a look at what’s in the view-models plugin and either stealing it verbatim or adapting to your own purposes.

The relavant code and gory details can be found here.

Spock's @AutoCleanup feature

Sun, 06 Feb 2011 12:22:53 +1100

You may have missed this little gem that was added to Spock in the 0.5 release…

import spock.lang

class InputStreamSpec extends Specification {

    @AutoCleanup
    def input = new FileInputStream("myfile.txt")

    def "some input stream tests"() {
        // …
    }

}

The spock.lang.AutoCleanup annotation works via Spock’s extension mechanism.

Let’s have a look at the documentation for @AutoCleanup (taken from the JavaDoc)…

spock.lang.AutoCleanup

Automatically cleans up the object stored in the annotated field or property at the end of its life time. More precisely, auto-cleanup of an object has the same effect as, and serves as a convenient replacement for, calling the object’s close method at the end of the spec’s cleanup method. @Shared objects are cleaned up at the end of the spec’s cleanupSpec method.

Customizing how cleanup is performed

By default, an object is cleaned up by invoking its parameterless close() method (which is assumed to exist); visibility and return type of this method are irrelevant. If some other method should be called instead, override the annotation’s value attribute:
@AutoCleanup("dispose") // invoke the object's "dispose" method
Cleaning up multiple objects

If multiple fields or properties are annotated with @AutoCleanup, their objects are cleaned up sequentially in reverse field/property declaration order, starting from the most derived class and walking up the inheritance chain.

Handling of exceptions during cleanup

If a cleanup operation fails with an exception, the exception is reported (just as if it had occurred in a cleanup or cleanupSpec method) and cleanup proceeds with the next annotated object. To prevent cleanup exceptions from being reported, override the annotation’s quiet attribute:
@AutoCleanup(quiet = true) // don't report exceptions

I find this extremely handy when testing some asynchronous code where I need an Executor as part of test fixture…

import spock.lang.*
import java.util.concurrent.Executors

class AsyncSpec extends Specification {

    @AutoCleanup("shutdown")
    def executor = Executors.newCachedThreadPool()

    def "some async bits"() {

    }

}

Over and above being very convenient, @AutoCleanup is great because it makes it easier to get your fixture setup out of your feature specifications and to also group fixture setup/teardown logic in one place.

Disabling Grails plugin upgrade confirmation

Thu, 06 Jan 2011 12:44:15 +1100

Quick one…

If you want to permanently disable plugin version change confirmations (e.g. when another developer has changed a plugin version in BuildConfig.groovy), simply add this to your scripts/_Events.groovy:

def resolveDependenciesWasInteractive = false
eventResolveDependenciesStart = {
    resolveDependenciesWasInteractive = isInteractive
    isInteractive = false
}

eventResolveDependenciesEnd = {
    isInteractive = resolveDependenciesWasInteractive
}

Annoying messages be gone.

Spock's new matching support

Sun, 10 Oct 2010 16:24:00 +1100

Spock has an interesting new feature coming in 0.5 (but its available now in recent builds of 0.5-SNAPSHOT) integrating the Hamcrest matching library, which is an API for testing that something meets certain criteria. It’s always been possible to use Hamcrest with Spock but there is now a more convenient syntax. The expressiveness of Groovy generally makes Hamcrest not quite as generally useful as it would be when testing with plain Java, but it can still make your tests more concise and expressive when you have complex matching to do.

A classic example is for matching a value against another value within a certain error margin. Hamcrest comes with the closeTo matcher for this. This is how you might use it in a JUnit test…

import static org.hamcrest.Matchers.closeTo
import static org.hamcrest.MatcherAssert.assertThat

class HamcrestTests extends GroovyTestCase {
    def testIt() {
        assertThat(1.9d, closeTo(2, 0.5))
    }
}

This test will pass because the actual value 1.9d (the d tells groovy it’s a Double and not a BigDecimal) is within ± 0.5 of 2. The closeTo method is what’s known as a matcher factory (i.e. it returns an instance of org.hamcrest.Matcher)

Using Spock’s new convenient matcher syntax, we write the above as…

import spock.lang.Specification
import static org.hamcrest.Matchers.closeTo

class HamcrestSpec extends Specification {
    void "test closeTo"() {
        expect:
        1.9d closeTo(2, 0.5)
    }
}

Nice and concise isn’t it. The syntax is essentially…

«value» «org.hamcrest.Matcher»

There is also another variant…

import spock.lang.Specification
import static spock.util.matcher.MatcherSupport.that
import static org.hamcrest.Matchers.closeTo

class HamcrestSpec extends Specification {
    void "test closeTo"() {
        expect:
        that 1.9d, closeTo(2, 0.5)
    }
}

This syntax has the advantage that it can be combined with the assert keyword so can be used outside of the then/expect blocks (which the shorthand version can’t).

import spock.lang.Specification
import static spock.util.matcher.MatcherSupport.that
import static org.hamcrest.Matchers.closeTo

class HamcrestSpec extends Specification {
    void "test closeTo"() {
        setup:
        assert that(1.9d, closeTo(2, 0.5))
    }
}

Custom Matchers

As previously mentioned, a lot of the stock matchers that come with Hamcrest are not as useful in Groovy as they are in Java due to Groovy’s many convenience methods and expressive syntax. However, you can easily write your own Hamcrest matchers that are particular to your problem domain to make your tests more concise and maintainable.

Let’s use the example of a Grails application that lets user’s read books online. There is a very simple security model; users and books both belong to groupings and a user must belong to at least one grouping that a book belows to to be allowed to read it. Here is what our domain looks like…

class Book {
    String name
    static hasMany = [groupings: Grouping]
    static belongsTo = Grouping
}
class User {
    String name
    static hasMany = [groupings: Grouping]
    static belongsTo = Grouping
}
class Grouping {
    String name
    static hasMany = [books: Book, users: User]
}

We could write a custom matcher that checks if a given user can read a given book…

import spock.lang.*
import grails.plugin.spock.*
import org.hamcrest.BaseMatcher
import org.hamcrest.Description
import static org.hamcrest.Matchers.not

class ReadabilitySpec extends IntegrationSpec {
    def "test readability"() {
        when:
        def user = new User(name: "u1").save()
        def book1 = new Book(name: "b1").save()
        def book2 = new Book(name: "b1").save()

        def grouping1 = new Grouping(name: "g1")
        grouping1.addToUsers(user)
        grouping1.addToBooks(book1)
        grouping1.save()

        def grouping2 = new Grouping(name: "g2")
        grouping2.addToBooks(book2)
        grouping2.save()

        then:
        user canRead(book1)
        user not(canRead(book2))
    }

    def canRead(book) {
        [
            matches: { user -> user.groupings.any { it in book.groupings } },
            describeTo: { Description description -> description.appendText("user in one of groupings ${book.groupings*.name}") }
        ] as BaseMatcher
    }
}

Here we have implemented the canRead matcher factory as an instance method on our spec class. We are also using Groovy’s ability to convert maps into objects that either extend a given class or implement an interface. Here we create a map with the methods that we need to override from the org.hamcrest.BaseMatcher class then use as BaseMatcher to have Groovy create a dynamic subclass for us at runtime (note that this has nothing to do with Spock’s matching support, I am just using it here for conciseness).

We could factor out our custom matcher into a real class and perhaps move the factory method to a separate class as a static method, making it reusable across our project. You could quite easily build up a library of convenient matchers that express your problem domain.

Summary

Spock’s new Hamcrest support is yet another great feature that makes your testing easier and more concise. It’s another great tool to have in your bag of tricks when writing tests. For more info and examples, you can check out the test case in the Spock project that exercises this stuff.

Getting more out of Property Override Configuration

Wed, 06 Oct 2010 15:41:57 +1100

The “Property Override Configuration” feature is an extremely useful technique for Grails applications. It allows you to specify the values for bean properties in your application configuration, which can be done externally and/or in an environment sensitive manner.

For example, we could easily control the number of simultaneous connections a particular service is allowed to make to a particular thing.

Here is our fictitious service…

class ThingService {
    def maxConnections
}

In our Config.groovy we might have…

beans {
    thingService {
        maxConnections = 10
    }
}

environments {
    test {
        beans {
            thingService {
                // only use 1 connection when testing
                maxConnections = 1 
            }
        }
    }
    production {
        // Load extra config from external location in production
        grails.config.locations = ["classpath:thing-config.groovy"]
    }
}

On the production classpath we might have a file called “thing-config.groovy” that has…

beans.thingService.maxConnections = 100

So we no have a default value of 10 for our maxConnections property, but overridden in test with a value of 1 and overridden in production with a value of 100. We can also change this value without a recompile in production (though you will need a restart).

That’s all well and good and pretty handy, but you can take it slightly further once you realise how this feature works.

Type Conversion

Property Override Configuration works at the bean definition level in Spring. This means that the value you specify is not directly assigned to the corresponding property on the bean in question, but rather is added to the bean definition before Spring goes to work creating your beans (which is effectively the same as changing the original bean definition). This means that you can take advantage of Spring’s rich type conversion features to do some rather cool things.

For example, we can make dealing with the filesystem easier by combining Spring’s resource support with the Property Override Configuration mechanism. Let’s assume we have a service that wants to read a text file that is on the classpath.

Here is our service…

class TextFileReadingService {
    File textFile
}

To populate that property you could either write the code yourself to create the instance, define a bean named textFile in resources.groovy and let autowiring set things up, or use Property Override Configuration. If we want to use Property Override Configuration, you might first try…

beans {
    textFileReadingService {
        textFile = new File(this.class.classLoader.getResource("theTextFile.txt").toURI())
    }
}

While that will work, there is an easier way…

beans {
    textFileReadingService {
        textFile = "classpath:theTextFile.txt"
    }
}

This works because Spring implicitly converts the String value we have given to a File object for us, and in doing this treats values with certain prefixes specially. This is part of Spring’s resource abstractions. Another useful prefix is “context:”, which resolves a file path relative to the root of the web app…

beans {
    textFileReadingService {
        textFile = "context:js/jquery.js"
    }
}

Your own beans

Note that Property Override Configuration is particularly useful when working with beans that we don’t define ourselves, such as services, taglibs, controllers etc. If we were defining our own beans and did not need environment sensitivity or externalisation of the value, we could use the same type conversion facilities when definining our beans directly.

If we had a class in src/groovy that looked like…

class TextFileReader {
    File textFile
}

We could create a Spring bean for it like so in resources.groovy…

beans = {
    textFileReader(TextFileReader) {
        textFile = "context:js/jquery.js"
    }
}

The point of this example being to illustrate that type conversion is not unique to Property Override Configuration.

Summary

Property Override Configuration is a surprisingly useful feature that is generally under publicised. It’s worth adding to your arsenal of techniques, especially combined with the type conversion that Spring offers.

Painless Page Identification with Geb & Grails

Thu, 26 Aug 2010 19:22:00 +1000

This will be a discussion of a handy pattern to use to make page identification simple and easy when working with Geb and Grails.

Geb and Page Identification

Geb supports (and encourages) using the Page Object Pattern. An aspect of this is having someway of being able to verify that the page object actually does represent the page that the browser is at. Consider filling out a form. When you submit the form you might expect to go to a confirmation page, but because of a validation error you get returned to the form page. In your test code after submitting the form you go on testing for things on the page and the results can be confusing. The best thing to do before testing parts of the page is to test that the page is indeed what you expect it to be. There are other reasons for page identification, but this is the main one.

Geb implements page identification through it’s “at checking”. In short, pages declare an “at” closure that contains some checks of the page structure, and returns true if the actual browser page is what the page object represents.

import geb.*

class ManualPage extends Page {
    static at = { $("h1", text: contains("Manual")) }
}

This “at check” is used implicitly when using the browser at(«PageClass») method…

Browser.driver {
    to ManualPage
    assert at(ManualPage) 
}

The at(«PageClass») method does two things:

Checks the browser’s page object is an instance of the given class
Checks the browser’s page object’s at checker returns true

The use of a Class with the at() method may seem strange. After using Geb for a short amount of time the reasons do become clear. Primarily, your test code is likely to not to declare page changes (such as when content declares a to property). This means that asserting the type of the current page object becomes important.

Writing a good at checker can be hard at times. You want to test enough so that you are sure the page is a match, yet you don’t want to test too much to make your checks fragile.

Grails and Conventions

Fortunately, Grails’ controller/action convention makes identifying pages cost free and definitive (for almost all cases). The trick lies in the controllerName and actionName variables being available in each action’s view implicitly. This allows you to make your Grails GSP templates look something like this…

<html>
<head>
  <meta name="pageId" content="${controllerName}.${actionName}" />
  …
</head>
<body>
  …
</body>
</html>

Every view generated from a controller action in your application now has a unique identifier embedded into the page in an unobtrusive manner.

Action Page Objects

Geb goes out of it’s way to support using inheritance with page objects. This means that you can define an at checker in a common base class that reads our meta pageId property and have that used for each subclass.

import geb.*

abstract class GrailsPage extends Page {

    // To be overridden by subclasses
    static controller = null
    static action = null

    static at = {
        // delegate here is the original page _instance_ (i.e. the subclass)

        def expectedPageControllerName = delegate.class.controller
        if (expectedPageControllerName == null) {
            throw new IllegalStateException("${delegate.class} forgot to declare which controller it belongs to")
        }

        def expectedPageActionName = delegate.class.action
        if (expectedPageActionName == null) {
            throw new IllegalStateException("${delegate.class} forgot to declare which action it is")
        }

        def actualPageControllerName = controllerName
        def actualPageActionName = actionName

        assert actualPageControllerName == expectedPageControllerName
        assert actualPageActionName == expectedPageActionName

        true // at checkers must return true
    }

    static content = {
        pageId { $("meta", name: "pageId").@content }
        controllerName { pageId.split('\\.')[0] }
        actionName { pageId.split('\\.')[1] }
    }

}

Here we do three things:

declare static ‘controller’ and ‘action’ properties that subclasses will populate (more on this later)
declare an “at checker” that compares the declared controller/action against those in the page
declare what the controllerName and actionName bits of content on the page are (consult the Book Of Geb for more on this content DSL)

We now have a rock solid page identification mechanism that from here on in in the development and testing of our application costs us almost nothing. The only thing you need to do when writing new page objects is set the controller and action static properties…

class ViewCartPage extends GrailsPage {
    static controller = "cart"
    static action = "view"
}

Or in the case where all your actions for a particular controller share content, you may want to have an abstract base class for all actions of that controller…

abstract class CartPage extends GrailsPage {
    static controller = "cart"
}

class ViewCartPage extends CartPage {
    static action = "view"
}

Geb and Inheritance (and Groovy)

This is made possible by Geb supporting inheritance of content definitions (content definitions are merged) and Groovy supporting a dynamic resolution of static methods and properties.

Given the above classes, the following works…

assert ViewCartPage.controller == "cart"

However, if we were calling this from Java, it would not work. In Java, static methods/properties are never inherited like they are for all intents and purposes in Groovy. This means that when requesting a page class’s “at checker” it will search the inheritance hierarchy for one (e.g. assert ViewCartPage.at == GrailsPage.at). This also means that at any point in the inheritance hierarchy you can override any static method/property defined in a super class (but it only works if calling from Groovy).

Summary

We discussed a useful pattern for page identification (“at checking” in Geb parlance) with Geb and Grails. I have used this pattern in anger and have found it to be very useful. Give it a try.

Annotation Driven Extensions With Spock

Wed, 18 Aug 2010 22:58:07 +1000

The following is an introduction to writing extensions with everybody’s favourite testing tool Spock. Like all things in Spock, extensions are easy to use and require little ceremony. We are going to build an extension that times various parts of test execution and blindly writes the times to standard out.

Please note that the API we are going to go through should not be considered stable/final.

We are building against Spock 0.5-SNAPSHOT and the following APIs may change on the road to 1.0.

Annotation Driven

Our extension is going to be annotation driven. We are going to provide an annotation that users can place on various parts of their specs. At the core of this is the IAnnotationDrivenExtension contract…

package org.spockframework.runtime.extension;

import java.lang.annotation.Annotation;
import org.spockframework.runtime.model.*;

public interface IAnnotationDrivenExtension<T extends Annotation> {
  void visitSpecAnnotation(T annotation, SpecInfo spec);
  void visitFeatureAnnotation(T annotation, FeatureInfo feature);
  void visitFixtureAnnotation(T annotation, MethodInfo fixtureMethod);
  void visitFieldAnnotation(T annotation, FieldInfo field);
  void visitSpec(SpecInfo spec);
}

You’ll notice that (almost) all of Spock’s internals are implemented in Java. In this exercise we will implement our extension bits in Groovy.

Annotation driven extensions implement the Visitor Pattern, and Spock will invoke your visitation method for each annotation of your type present on the spec (We’ll discuss the visitSpec() method later).

visitSpecAnnotation() - is called when the spec class is annotated.
visitFeatureAnnotation() - is called for each “feature” (i.e test method).
visitFixtureAnnotation() - is called for each of the setupSpec(), setup(), cleanup() and cleanupSpec() methods that are annotated.
visitFieldAnnotation() - is called for each spec instance variable.
visitSpec() - is always called after all of the visitation methods. This allows you to collect a model while visiting, then decorate the spec in some manner.

These methods all take the annotation instance and an info object which describes the annotated thing. For more detail on each of these info types above what we will go through in this exercise, check them out in the Spock source. They are pretty straightforward.

The Annotation

We need to wire our annotation up to our extension. We declare our annotation like normal, but annotate it with the IAnnotationDrivenExtension implementation that backs it.

import java.lang.annotation.*
import org.spockframework.runtime.extension.ExtensionAnnotation

@Retention(RetentionPolicy.RUNTIME)
@Target([ElementType.TYPE, ElementType.METHOD])

@ExtensionAnnotation(TimingExtension)

public @interface Time {}

Here we have declared a new annotation called @Time that takes no parameters and can be placed on types (in our context, the spec class) and methods. The @ExtensionAnnotation meta annotation is how tell Spock who deals with the @Time annotation.

The Extension

Now we need to actual implement our extension. As you would expect, Spock provides a AbstractAnnotationDrivenExtension super class that we can use. This allows us to only implement the methods we need to. In our case, we don’t need the visitFieldAnnotation() method.

import org.spockframework.runtime.extension.AbstractAnnotationDrivenExtension
import org.spockframework.runtime.model.SpecInfo
import org.spockframework.runtime.model.FeatureInfo
import org.spockframework.runtime.model.MethodInfo

class TimingExtension extends AbstractAnnotationDrivenExtension<Time> {
  def timeSpec = false
  def timedFeatures = []

  void visitSpecAnnotation(Time annotation, SpecInfo spec) {
    timeSpec = true
  }

  void visitFeatureAnnotation(Time annotation, FeatureInfo feature) {
    timedFeatures << feature.name
  }

  void visitSpec(SpecInfo spec) {
    spec.addListener(new TimingRunListener(timeSpec, timedFeatures)
  }
}

Here we simply collect information on which things we are timing, then add a run listener (explained below) that will do the timing.

The implementation of the visitation methods in AbstractAnnotationDrivenExtension always throw an org.spockframework.runtime.InvalidSpecException. Our annotation can legally be placed on any fixture methods according to it’s definition, but that doesn’t make sense in the context of our extension. Because we have not overridden the visitFixtureAnnotation() method in our extension, if the user annotates a fixture method with @Time, they will get a nice error message from Spock that tells them that that is invalid.

It’s important to consider that there is guaranteed to only ever be one instance of an extension for each spec. Spock will create an instance of your extension the first time it encounters your annotation, and then reuse that instance when it encounters later annotations (in the same spec).

Listening In

Spock has it’s own execution listening API specified by IRunListener.

package org.spockframework.runtime;

import org.spockframework.runtime.extension.builtin.StepwiseExtension;
import org.spockframework.runtime.model.*;

public interface IRunListener {
  void beforeSpec(SpecInfo spec);
  void beforeFeature(FeatureInfo feature);
  void beforeIteration(IterationInfo iteration);
  void afterIteration(IterationInfo iteration);
  void afterFeature(FeatureInfo feature);
  void afterSpec(SpecInfo spec);
  void error(ErrorInfo error);
  void specSkipped(SpecInfo spec);
  void featureSkipped(FeatureInfo feature);
}

This is all pretty straightforward, but you may be wondering about beforeIteration() and afterIteration(). This are for parameterised (or data-driven) feature methods and are called for each set of parameters.

Again, we have convenient super class to work with.

import org.spockframework.runtime.AbstractRunListener;
import org.spockframework.runtime.model.*;

class TimingRunListener extends AbstractRunListener {

  def timeSpec = false
  def specStartTime
  def featureStartTimes = [:]

  TimingRunListener(timeSpec, timedFeatures, timedFixtures) {
    this.timeSpec = timeSpec
    timedFeatures.each { featureTimes[it] = null }
  }

  private now() {
    System.currentTimeMillis()
  }

  private start(name) {
    println "starting $name …"
  }

  private done(name, started, finished = now()) {
    println "$name took ${finished - started} milliseconds"
  }

  void beforeSpec(SpecInfo spec) {
    if (timeSpec) {
      specStartTime = now()
      start("spec '$spec.name'")
    }
  }

  void beforeFeature(FeatureInfo feature) {
    if (featureStartTimes.containsKey(feature.name)) {
      featureStartTimes[feature.name] = now()
      start("feature '$feature.name'")
    }
  }

  void afterFeature(FeatureInfo feature) {
    def startedAt = featureStartTimes[feature.name]
    if (startedAt) {
      echo("feature '$feature.name'", startedAt)
    }
  }

  void afterSpec(SpecInfo spec) {
    if (specStartTime) {
      echo("spec '$spec.name'", specStartTime)
    }
  }
}

Our extension is now complete… let’s try it out.

In Action

Now all we have to do is annotate our spec…

import spock.lang.*

@Time
class DoingStuff extends Specification {

  @Time
  def "a b c"() {
    when:
    Thread.sleep(1000)
    then:
    true
  }

}

If we were to run this spec we would see something like…

starting spec 'DoingStuff' …
starting feature 'a b c' …
feature 'a b c' took 1000 milliseconds
spec 'DoingStuff' took 1500 milliseconds

Obviously the times are made up but you get the point.

The Real World

Spock ships with a bunch of extensions (as of today in 0.5-SNAPSHOT):

@AutoCleanup - allows a named cleaning up/closing method to be automatically called by Spock on a field
@FailsWith - makes a feature pass only if it raises a certain exception and it’s uncaught
@Ignore - prevents the feature or spec from running
@IgnoreRest - prevents every other feature from running
@RevertMetaClass - undoes any changes to the specified to meta classes of the specified classes during the feature (or spec)
@Stepwise - causes each feature method to be executed in declaration order and any after the first failure to be ignored (i.e. story mode)
@Timeout - causes a method to fail if it takes to long (and will interrupt it if it does take too long)

For more info on any of these extensions, check out their javadoc comments.

You could very easily make your own extensions specific to your projects to make your life easier. You could load data fixtures, establish connections… all kinds of things.

Summary

So that’s “Annotation Driven Extensions” with the Spock Framework.

Go forth and create some… and may the force be with you (wait… what?)

Proposal: Grails Plugin Collective

Mon, 07 Jun 2010 21:29:02 +1000

The following is a proposal for, and a request for comment on, the idea of a semi-structured combination of social and technological systems and norms to initiate, develop and maintain Grails plugins.

The Problem Being Addressed

Typically, a plugin is born through inspiration or necessity. It’s not uncommon that the original author at some point stops maintaining or developing a frequently-used or promising plugin. There are many reasons for this and they are in no way unique to the Grails ecosystem. People contribute and move on as is their want and well intentioned developers can quickly lose interest in developing a plugin due to roadblocks and lack of knowledge, experience and feedback.As a Software Developer using Grails professionally, the availability of a high quality plugin makes a significant product difference; and conversely an unsuccessful attempt to use a plugin due to bugs or lack of documentation costs real time. Often when finding an issue and fixing it, getting that fix back into the community takes considerable effort in coordinating with the plugin developer/maintainer who may or may not be around.

As a plugin developer, during busy times it can be hard to keep up with bug reports, feature requests and Grails upgrades. It’s also concerning that knowledge and understanding of the plugins I have authored rest largely with myself, creating a single point of failure. It would be much better if there were other people who could (and did) maintain and improve things in my (or any other author’s) absence.

The Proposed Solution

To remedy this situation, I propose that a self-organised, distributed, democratic, collective be formed… to foster, develop and maintain Grails plugins. I am calling this idea the “Grails Plugin Collective” for the time being.

The social structure is what would be the most interesting and, ultimately, enabling. It would allow members to work across plugins, scratching their own itches, and getting those fixes/features into release with minimal effort without risking quality. It would also enable steering and guiding the direction of plugins while allowing members to freely propose ideas and alternatives. Due to Grails’ “convention over configuration” nature, this becomes critically important. Hopefully, the collective wisdom of a group of individuals results in a highly consistent, conventional approach to how plugins work.

Goals and Aims

Create a community of volunteer skilled developers
Support the recognition of official membership (primarily for CVs)
Establish a set of useful, well used and high quality Grails plugins
Encourage outside contributions, both one-off and in working towards membership
Ensure adequate levels of documentation in a consistent format for all collectivised plugins
Ensure proper quality control mechanisms such as code coverage and developer documentation

Relationship with VMWare and certification

I propose that the collective should be an entity outside of VMWare. This does not exclude VMWare employees from participating in the collective by any means, or from having some kind of special role. It purely means that the entity is not bound to VMWare in any way other than through the licensing arrangement of any software owned by VMWare.

I also propose that if a plugin certification scheme is ever established, it be done completely separately to the collective. I imagine that many of the collectivised plugins would aim for certification if at all possible, but in this respect they would be no different to other community plugins.

Procedures and Principles

The collective should aim to operate with the least amount of bureaucracy and procedure that is required. The core idea is that as a democratic structure, all proposals are put to a vote. Members will have a relatively short time frame (proposed: 48 hours) to vote. A certain proportion of the votes cast must be affirmative for the proposal to succeed. It’s likely that there would also be some sort of veto mechanism for things that are extremely time critical.

I image the following kinds of things would be voted on:

API/Design questions & changes
Releases
Quality and process standards
Developer membership
Acceptance of new plugins

Initial Membership

Being that what is being proposed is a self-organising, democratic social structure, I am hesitant to be to prescriptive about how such a thing might work in terms of my vision. I am interested in getting other people’s ideas.

An initial membership also needs to be put together. This will be somewhat of a challenge for a democratic outfit. To get the ball rolling, I suggest that the VMWare Grails team propose an initial membership of roughly 10 people (likely including themselves). From there, the collective can self organise and induct new members over time.

So what are your thoughts? Is such an initiative worthwhile? Could it work? Could it succeed in raising and maintaining the quality of selected Grails plugins? Are there other such initiatives that we could learn from? What kind of social practices could be put in place to support rapid development while maintaining consistency and quality?

Feel free to leave your opinion either here or on the grails-user mailing list.

Putting the Artefact API to work in your Grails app

Tue, 01 Jun 2010 22:42:00 +1000

I haven’t seen many cases of people putting the Grails’ artefact API to use in their application. It’s likely that most Grails’ users aren’t aware that it exists, which in many ways is a good thing… it is after all an implementation concern.

You can however put it to work in your own application.

What is it?

Perhaps it’s best to discuss what an artefact is in Grails first. An example of an artefact is a service class. Think of what happens when your grails application starts; it finds all the service classes, creates an instance of each (typically) and autowires the dependencies. Grails defines a class whose instances represent a single service class and an associated handler. This is what I am collectively calling the Artefact API.

Why use it?

The biggest reason these days is by far the hot reloading support. That is, if you change an artefact class while the application is running, Grails (with some help from you) will reload the class and you get the changes without a restart. Of course, we are all familiar with this.

There is a more subtle benefit though. You may have some kind of prominent & pervasive concept in your application (like a service is a concept). You might find that creating an artefact for this concept can make your life easier.

An example use case

Consider some kind of eStore, with a wide range of products. Our products have simple persistence requirements but can have wildly varying behaviours in the system, which are likely to get more complex over time. I try to avoid extensive subclassing of domain objects when the classes primarily vary in behaviour and not data. So we need to find another way to implement the varying behaviour.

The `ProductHandler`

Each product is going to provide a handler (terrible name I know) that is responsible for the majority of the product’s behaviour. Here is our product domain class…

class Product {
    String name
    
    // don't want to try and persist the handler
    static transients = ['handler'] 
    
    ProductHandler getHandler() {
        // somehow get the handler for this product
    }
}

And we have a ProductHandler interface for good measure…

interface ProductHandler {
    void setProduct(Product)
    boolean isCanBeSold()
}}

A non artefact solution

One kind of traditional approach would be to have each product persist a key that refers to a particular product handler, and to have each product handler class register itself with some kind of registry.

class Product {
    String name
    String handlerKey
    
    def productHandlerService // autowired 
    
    // don't want to try and persist the handler
    static transients = ['handler']
    
    protected handler
    ProductHandler getHandler() {
        if (!handler) {
            handler = productHandlerService[this]
        }
        handler
    }
}

// Our registry
import grails.spring.BeanBuilder
class ProductHandlerService {
    def grailsApplication // autowired
    static private registry = [:].asSynchronized()
    
    static register(String key, Class handlerClass) {
        registry[key] = handlerClass // should check that handlerClass implements ProductHandler
    }
    
    protected createBeanBuilder() {
        new BeanBuilder(grailsApplication.mainContext, grailsApplication.classLoader)
    }
    
    protected instantiateHandler(handlerClass, Product product) {
        createBeanBuilder().with {
            beans {
                handler(handlerClass, product: product) {
                    // autowire the handler so it can use services etc.
                    it.autowire = true
                }
            }
            createApplicationContext().getBean('handler')
        }
    }
    
    def getAt(Product product) {
        def handlerClass = registry[product.handlerKey] // assume there is always a handler
        instantiateHandler(handlerClass, product)
    }
}

// Example Handler (in src/groovy dir)
class OnlyOnTuesdayProductHandler implements ProductHandler {
    static {
        ProductHandlerService.register('onlyOnTuesday', OnlyOnTuesdayProductHandler)
    }
    Product product
    boolean isCanBeSold() {
        new GregorianCalendar().get(Calendar.DAY_OF_WEEK) == Calendar.TUESDAY
    }
}

This will get the job done (albeit in a cumbersome way), but it suffers from ProductHandler implementations not being hot-reloadable.

Creating a `ProductHandler` artefact

We can make things a bit easier and support hot reloading by creating an artefact for product handlers.

To do this we need a plugin…

class ProductHandlerGrailsPlugin {
    def version = "0.1"
    def grailsVersion = "1.2.* > *"
    
    // register the artefact handler
    def artefacts = [ProductHandlerArtefactHandler]
    
    // watch for any changes in these directories
    def watchedResources = [
        "file:./grails-app/productHandlers/**/*ProductHandler.groovy",
        "file:../../plugins/*/productHandlers/**/*ProductHandler.groovy"
    ]
    
    // Grails calls this when one of the files matching 'watchedResources' changes.
    // We have to actually swap in the new class when the source changes
    // There isn't anything special here, it's just boilerplate.
    def onChange = { event ->
        if (application.isArtefactOfType(ProductHandlerArtefactHandler.TYPE, event.source)) {
            def oldClass = application.getProductHandlerClass(event.source.name)
            application.addArtefact(ProductHandlerArtefactHandler.TYPE, event.source)

            // Reload subclasses
            application.productHandlerClasses.each {
                if (it.clazz != event.source && oldClass.clazz.isAssignableFrom(it.clazz)) {
                    def newClass = application.classLoader.reloadClass(it.clazz.name)
                    application.addArtefact(ProductHandlerArtefactHandler.TYPE, newClass)
                }
            }
        }
    }
}

We also need a artefact handler implementation (which has to be in Java due to legacy reasons)…

import org.codehaus.groovy.grails.commons.ArtefactHandlerAdapter;

public class ProductHandlerArtefactHandler extends ArtefactHandlerAdapter {

    // the name for these artefacts in the application
    static public final String TYPE = "ProductHandler"; 

    // the suffix of all product handler classes (i.e. how they are identified as product handlers)
    static public final String SUFFIX = "ProductHandler"; 
    
    public ProductHandlerArtefactHandler() {
        super(TYPE, ProductHandlerClass.class, DefaultProductHandlerClass.class, SUFFIX);
    }
}

And a ProductHandlerClass interface (again in Java)…

import org.codehaus.groovy.grails.commons.GrailsClass;

public interface ProductHandlerClass extends GrailsClass {}

And a DefaultProductHandlerClass implementation of that interface (again in Java)…

import org.codehaus.groovy.grails.commons.AbstractGrailsClass;
import org.codehaus.groovy.grails.commons.GrailsClassUtils;
 
public class DefaultProductHandlerClass extends AbstractGrailsClass implements ProductHandlerClass {

    public DefaultProductHandlerClass(Class clazz) {
        super(clazz, ProductHandlerArtefactHandler.SUFFIX);
    }
    
    // This method will get the static property 'key' on the underlying 
    // ProductHandler class that it represents.
    public String getKey() { 
        Object key = GrailsClassUtils.getStaticPropertyValue(getClazz(), "key");
        if (key == null) {
            return null;
        } else {
            return key.toString();
        }
    }
}

That’s a shotgun intro to the Grails Artefact API classes like GrailsClass and ArtefactHandlerAdapter just covering the stuff we need. Check out the linked to source for deeper detail.

Here is what we have done…

Create a plugin that registers an artefact handler for product handlers
Register for changes to source in grails-app/productHandlers in the app and plugins
Provide an onChange handler that reloads product handler classes when they change
Provide an ArtefactHandler implementation that specifies what a product handler class is
Provide a GrailsClass subinterface for product handler classes
Provide an implementation of that interface that returns the static property key on the underlying class (among other things)

Putting it together

Armed with our new artefact, we can now simplify our initial implementation…

// Our registry
import grails.spring.BeanBuilder
class ProductHandlerService {
    def grailsApplication // autowired
    
    protected createBeanBuilder() {
        new BeanBuilder(grailsApplication.mainContext, grailsApplication.classLoader)
    }
    
    protected instantiateHandler(handlerClass, Product product) {
        createBeanBuilder().with {
            beans {
                handler(handlerClass, product: product) {
                    // autowire the handler so it can use services etc.
                    it.autowire = true
                }
            }
            createApplicationContext().getBean('handler')
        }
    }
    
    def getAt(Product product) {
        def productHandlerClasses = grailsApplication.productHandlerClasses // a list of DefaultProductHandlerClass
        def handlerClass = productHandlerClasses.find { it.key == product.handlerKey } // find the one with the matching key
        instantiateHandler(handlerClass, product)
    }
}

// Example Handler (in grails-app/productHandlers dir)
class OnlyOnTuesdayProductHandler implements ProductHandler {
    static key = 'onlyOnTuesday'
    Product product
    boolean isCanBeSold() {
        new GregorianCalendar().get(Calendar.DAY_OF_WEEK) == Calendar.TUESDAY
    }
}

Being more conventional

Each of our product handler classes must specify a key, that products use to link themselves to a particular handler implementation. You could do away with this, and infer the key from the class name quite easily.

class ProductHandlerService {
    // …snip…
    
    def getAt(Product product) {
        def handlerClass = grailsApplication.getProductHandlerClass(product.handlerKey)
        instantiateHandler(handlerClass, product)
    }
}

The grailsApplication.getProductHandlerClass() method given the value "onlyOnTuesday" would return the OnlyOnTuesdayProductHandler class object.

In this particular case I personally wouldn’t do this as every time I renamed a product handler class I would have to update the products that use that handler in the DB, but other situations may not have this issue.

Summary

All product handler classes are now reloadable, which would obviously be a substantial productivity boost, without all that much work on our part. This approach could be used for any kind of concept or set of classes in your application that don’t fit into the standard controller, service, taglib etc. pattern.

The Artefact API can seem a bit confusing if you don’t take into consideration that this was the heart of Grails in the early days. It’s still there and is used by a great many plugins (e.g. grails-quartz) as well as being used extensively internally in Grails, but it doesn’t quite have the same role that it used to.

Hopefully this has shown you how you can, and why you might want to, use the artefact API internally in your applications.

Forwarding/Chaining and models in Grails

Mon, 24 May 2010 14:35:25 +1000

I recently hit the case where I need to forward a request in Grails to a second action, but that action needed access to the model generated by the first (note that this is different to params). The Grails documentation doesn’t mention the ability to pass models when forwarding at all, but if you check the source code you can see that the capability is there.

What’s also missing is how to access the existing model in a forwarded to or chained to action. If you trace the code, you see that the model eventually gets passed to Spring’s [WebUtils.exposeRequestAttributes()](http://static.springsource.org/spring/docs/current/javadoc-api/org/springframework/web/util/WebUtils.html#exposeRequestAttributes(javax.servlet.ServletRequest, java.util.Map)) method, that simply makes each item in the model a request attribute. So in Grails you can access them via the request variable…

class MyController {
    
    def first = {
        forward(action: 'second', model: [thing: "thing"])
    }
    
    def second = {
        assert request.thing == "thing"
        // go forth and do stuff
    }
    
}

Why use model instead of params?

Params can only be strings where as you can pass any type via the model.

Custom Grails Test Types/Phases

Thu, 20 May 2010 21:21:04 +1000

Recently there was a query on the grails-user mailing list asking how to create a separate test suite (in the poster’s terminology). In Grails’ terminology, what the poster wanted was a separate test type that could be run separately.

The following is an expansion on the solution offered in the thread.

There are two core concepts in the test system; types and phases.

Test Phases

A test phase refers to the state of the application at test time. Grails comes with 4…

Unit - no application state, only the classpath is configured
Integration - application running (e.g. database, beans), but not listening for http requests
Functional - application is fully running
Other - same as Unit

Here’s how to create your own test phase.

In your scripts/_Events.groovy file…

// 1. add the name of your phase to this variable with this event handler
eventAllTestsStart = {
    phasesToRun << "custom"
}

// 2. Create a «phase name»Tests variable containing a list of test types (more on this later)
customTests = ["custom"]

// 3. Create pre and post closures
customTestPhasePreparation = {
    // called at the start of the phase
}
customTestPhaseCleanUp = {
    // called at the end of the phase
}

Even if you don’t have anything to do in your Preparation and CleanUp closures, you still need to create empty ones.

Note that the name of a test phase has no real correlation to it’s type’s names. In this example we just happen to have a type with name custom in a phase named custom.

Mimicking standard phases

If you need your phase to be like one of the standard phases, just call that phase’s handlers…

customTestPhasePreparation = {
    integrationTestPhasePreparation()
}
customTestPhaseCleanUp = {
    integrationTestPhaseCleanUp()
}

That’s all there is to it.

Test Types

A test type is really two things; a grouping of tests and a test running mechanism.

Above we had…

…
// 2. Create a «phase name»Tests variable containing a list of test types (more on this later)
customTests = ["custom"]
…

The «phaseName»Tests lists contains a phase’s test types. These must either be String’s or instance of GrailsTestType. Writing a GrailsTestType implementation will be the subject of a future article (if you are interested, start with the JavaDoc on GrailsTestType and then look at implementations in the wild like the one from the Spock plugin).

Grails ships with the JUnit4GrailsTestType which is what Strings get implicitly converted to (this happens here) for both convenience and legacy reasons.

Test types are associated to a certain directory (under test) and one or more class name suffixes. The JUnit test type uses the suffix Tests pre Grails 1.3 and Tests and Test in Grails 1.3. The directory for String test types is the value (i.e. test/custom for our above example).

Pre and post test type handlers

You don’t need to write pre/post handlers for types like you do with phases. But should you need to, here is how you do it…

eventTestSuiteStart = { typeName ->
    if (typeName == 'custom') {
        // do stuff
    }
}

eventTestSuiteEnd = { typeName ->
    if (typeName == 'custom') {
        // do stuff
    }
}

The event has that name due to legacy reasons.

Types in integration or functional phases

Above we created an integration-like phase called custom. Without a bit of extra work, our tests won’t be completely like standard integration tests in that they won’t have transaction rollback and other bits and pieces. To do this you need to register a JUnit4GrailsTestType so it can be configured. Here is a complete example on how you would do this…

import org.codehaus.groovy.grails.test.junit4.JUnit4GrailsTestType

// 1. add the name of your phase to this variable with this event handler
eventAllTestsStart = {
    phasesToRun << "custom"
}

// 2. Create a custom test type
def testTypeName = "custom"
def testDirectory = "custom"
def testMode = new GrailsTestMode(autowire: true, wrapInTransaction: true, wrapInRequestEnvironment: true)
def customTestType = new JUnit4GrailsTestType(testTypeName, testDirectory, testMode)

// 3. Create a «phase name»Tests variable containing the test type(s)
customTests = [customTestType]

// 4. Create pre and post closures
customTestPhasePreparation = {
    integrationTestPhasePreparation()
}
customTestPhaseCleanUp = {
    integrationTestPhaseCleanUp()
}

For a functional-like phase you would do…

import org.codehaus.groovy.grails.test.junit4.JUnit4GrailsTestType

// 1. add the name of your phase to this variable with this event handler
eventAllTestsStart = {
    phasesToRun << "custom"
}

// 2. Create a custom test type
def testTypeName = "custom"
def testDirectory = "custom"
def testMode = new GrailsTestMode(autowire: true)
def customTestType = new JUnit4GrailsTestType(testTypeName, testDirectory, testMode)

// 3. Create a «phase name»Tests variable containing the test type(s)
customTests = [customTestType]

// 4. Create pre and post closures
customTestPhasePreparation = {
    functionalTestPhasePreparation()
}
customTestPhaseCleanUp = {
    functionalTestPhaseCleanUp()
}

(functional tests don’t need rollback transactions or fake request environments)

For completeness, here’s a unit-like phase (though you could just use a String)…

import org.codehaus.groovy.grails.test.junit4.JUnit4GrailsTestType

// 1. add the name of your phase to this variable with this event handler
eventAllTestsStart = {
    phasesToRun << "custom"
}

// 2. Create a custom test type
def testTypeName = "custom"
def testDirectory = "custom"
def customTestType = new JUnit4GrailsTestType(testTypeName, testDirectory)

// 3. Create a «phase name»Tests variable containing the test type(s)
customTests = [customTestType]

// 4. Create pre and post closures
customTestPhasePreparation = {
    unitTestPhasePreparation()
}
customTestPhaseCleanUp = {
    unitTestPhaseCleanUp()
}

Running your phase/type

Once registered and configured, your custom tests can be run just like any other tests using grails test-app. You can even target them like normal…

grails test-app custom: // run all types in the custom phase
grails test-app :custom // run the custom type in all phases
grails test-app custom:custom // run the custom type in the custom phase

You can even target tests and test methods

grails test-app custom:custom Person* Product.testSave

The above example would run all test classes starting with Person (and ending in Test or Tests) and the testSave test in ProductTest or ProductTests.

The Grails manual has a section on running tests.

Not having your type run by default

The original email query was asking for a solution for having a test type that didn’t run with grails test-app, but ran when explicitly requested. Given the above, the following should make sense…

eventAllTestsStart = { 
    if (testOptions.customOnly) { 
        phasesToRun = ["integration"] // remove the other phases 
        integrationTests = [] // remove the normal integration  tests 
        addCustomTestType() 
    } else if (testOptions.withCustom) { 
        addCustomTestType() 
    } 
} 

addCustomTestType = { 
        integrationTests << "ipbx"
}

(The testOptions map contains all switch or parameter style arguments passed to grails test-app)

So this gives us…

grails test-app // don't run the custom type
grails test-app -only-custom // run ONLY the custom type
grails test-app -with-custom // run ALL types including our custom type

Why isn’t this in the manual?

Laziness on my part. This article will likely be the basis of what will end up in the manual (GRAILS-6301).

Grails, WebTest and JQuery.

Thu, 11 Mar 2010 15:16:30 +1100

The recently released grails-webtest 2.0.2 now installs WebTest via dependency resolution.

This allows you to work around the HTMLUnit 2.4 incompatibility with JQuery. WebTest 3.0 depends on HTMLUnit 2.4, but we can force the use of HTMLUnit 2.5 which works with JQuery.

Simply add it as a dependency in your app.

grails.project.dependency.resolution = {
    inherits "global"
    log "warn"

    repositories {
        grailsHome()
        mavenCentral()
    }
  
    dependencies {
        test('net.sourceforge.htmlunit:htmlunit:2.5') {
            excludes 'xalan' // IVY-1006 - use xalan 2.7.0 to avoid (see below)
            excludes 'xml-apis' // GROOVY-3356
        }
        test('xalan:xalan:2.7.0') {
            excludes 'xml-apis' // GROOVY-3356
        }
    }
}

Scoped Services & Proxies in Grails

Tue, 09 Mar 2010 21:46:00 +1100

Update: I have released a plugin that makes working with scoped proxies a little bit easier.

Grails has supported “scoping” services for as long as I have been working with it. Surprisingly, you very rarely here of people using this feature. For my money, it’s one of the lowest cost techniques available to avoid the inherent spaghetti in referencing the session and request (for all intents and purposes) global objects.

This feature is built on top of Spring’s bean scoping. However, you don’t need to know much Spring to get value out of this in Grails.

Scoping a service is as simple as declaring a static scope property with the name of the desired scope…

class MyScopedService {
    static scope = 'session'
}

So now, for each distinct session there will be a distinct instance of MyScopedService in our application.

A shopping cart as a service

An easy to understand use case for this might be a shopping cart…

class CartService {
    static scope = 'session'
    
    
    void addCartItem(cartItem) {
        // …
    }
    
    def getPrice() {
        // …
    }
}

We would use this in our controller like so…

class CartController {
    
    def cartService
    
    def addItem = {
        cartService.addItem(/* cart item */)
    }
    
    def price = {
        println "Cart price is: " + cartService.price
    }
}

You might be wondering just which session that cartService belongs to. Grails controllers are prototype scoped beans (which means a new one is created whenever it is retrieved from the application context) and only ever created inside of a request environment. Therefore, a Grails controller always lives within the context of a session. So when the controller instance is created by Grails at the start of the request, it can be injected with the instance of cartService that correlates to the session that the request is for.

But what about objects that don’t live inside a request (like taglibs)? For that we need a scoped proxy.

Using proxies to deal with scope differences

So we want to have a taglib that renders the current price of the shopping cart. We could pass the cartService instance to the view layer via our controller action and then pass it to the taglib, but that gets tiresome real quick when you start doing it for lots of actions. Since our cart is now a Spring managed bean we could try adding it as a dependency of our taglib…

class CartTagLib {
    
    def cartService
    
    def price = {
        out << cartService.price
    }
}

If you try and do this you are going to get…

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cartService': Scope 'session' is not active for the current thread;

Grails taglibs are singleton scoped so are created at application startup when the notion of session doesn’t make any sense. What we can do though is create a singleton proxy that delegates to the relevant cartService object at execution time (taglibs are always executed during a request so there will be session when the tag is executed).

With Grails 1.2 and earlier, we have to create this proxy manually by adding this to grails-app/conf/resources.groovy…

import org.springframework.aop.scope.ScopedProxyFactoryBean

beans = {
    cartServiceProxy(ScopedProxyFactoryBean) {
        targetBeanName = 'cartService'
        proxyTargetClass = true
    }
}

This, in effect, creates a singleton bean, which is a dynamically generated subclass of CartService, that delegates method/property calls to the cartService instance stored in the session. Check out Spring’s docs on scope proxies if you want more information on this.

Now we just rewrite our taglib to use our proxy…

class CartTagLib {
    
    def cartServiceProxy
    
    def price = {
        out << cartServiceProxy.price
    }
}

You can now use your cartServiceProxy anywhere like other services or filters. As long as the code that calls cartServiceProxy is executed in a request environment everything will work as expected in a completely thread safe manner.

Some notes on Grails 1.3 improvements

Grails 1.3 will make scoped beans even more attractive by removing the need to define your own proxies. All you will have to do is…

class CartService {
    static scope = 'session'
    static proxy = true
}

To have a proxy named cartServiceProxy created for you. You can track this new feature via the Grails issue tracker.

Grails 1.3 will also support scoped tag libs in the same manner as services.

Testing and scoped services

When integration testing scoped services, you need to be aware of the request/session lifecycle semantics.

Each test method is run in it’s own unique environment. This means two things; you must use a proxy to access a request or session scoped in a test, and each test method will have it’s own distinct underlying service instance.

class SomeTests extends GroovyTestCase {

import grails.plugin.spock.*

class ScopedServiceSpec extends IntegrationSpec {
 
    def sessionScopedServiceProxy
    def requestScopedServiceProxy
    
    void test1() {
        expect:
        sessionScopedServiceProxy.property == null
        requestScopedServiceProxy.property == null
        when:
        sessionScopedServiceProxy.property = 1
        requestScopedServiceProxy.property = 1
        then:
        sessionScopedServiceProxy.property == 1
        requestScopedServiceProxy.property == 1
    }

    void test2() {
        expect:
        sessionScopedServiceProxy.property == null
        requestScopedServiceProxy.property == null
        when:
        sessionScopedServiceProxy.property = 2
        requestScopedServiceProxy.property = 2
        then:
        sessionScopedServiceProxy.property == 2
        requestScopedServiceProxy.property == 2
    }
}

Why use scoped services and proxies?

For me it’s really about expressing intent. Some aspects of your application, like a shopping cart, are so pervasive that they end up everywhere in your code. It’s very hard to track down who is getting something from or setting something in the session or request objects in controllers, taglibs or filters. If you use scoped services, it’s very easy to see who is doing what. I can tell a controller does something with the cart because I see def cartService at the start of the class. That’s easier to spot than session.cart buried in an action. I also find it allows me to stay more focussed in the language of my problem domain.

Scoped services are a great tool to have in your arsenal. In an upcoming post, I’ll be discussing using custom scopes or lifecycles for your scoped services.

Configuration based Spring bean definition with Grails.

Tue, 09 Mar 2010 10:42:53 +1100

I released a new version of the Grails JMS plugin (0.5) over the weekend. This release features completely rewritten internals to expose every configuration aspect of the underlying Spring JMS classes. JMS is a complicated topic with lots of setup and configuration options so this level of access is necessary.

What’s novel about the approach is that it allows users to configure the underlying beans via the Grails application config, rather than via direct Spring bean configuration. This has the advantage of being more generally accessible as a lot of Grails developers still shy away from directly configuring beans. It also has the advantage of allowing the plugin to assert a certain level of control over the bean definitions.

A little bit about Grails JMS

The plugin makes it convenient to specify service methods as JMS listeners.

import grails.plugin.jms.Subscriber

class ListeningService {
    
    @Subscriber
    void interestingStuff(payload) {
        
    }
    
}

Whenever a message is sent to the topic “interestingStuff”, the message will be delivered to this service method.

There are two aspects to receiving JMS messages with Spring’s JMS support; containers and adapters. For each listener there is a distinct container and adapter pair. In a plain Spring app, you would configure a pair of these beans to receive your messages. If you have a look at those classes, there are a lot of config options. The goal of this plugin release was to give you access to those options should you need it, but not force you to define everything yourself.

The @Subscriber annotation has container and adapter parameters that default to "standard". These parameters are the names of the abstract beans that the concrete listener and adapter instances shall inherit from. There are implicit suffixes though; a container value of "standard" actually means the bean standardJmsListenerContainer and so forth. The plugin does force some properties on the concrete instances, but very few. The majority of configuration is controlled by the abstract base.

Config based bean definitions

The other half of the story is how the beans are defined based on the config. This is driven by the MapBasedBeanDefinitionBuilder that takes a name and Map of properties a certain format and registers a bean based on the map data. There are also certain MapBasedBeanDefinitionBuilder subclasses in the plugin like JmsListenerContainerAbstractBeanDefinitionBuilder that specialise in creating certain types of beans.

The default set of beans configurations look like this…

import org.springframework.jms.support.converter.SimpleMessageConverter
import org.springframework.jms.listener.DefaultMessageListenerContainer

templates {
    standard {
        connectionFactoryBean = "jmsConnectionFactory"
        messageConverter = new SimpleMessageConverter()
    }
}
containers {
    standard {
        concurrentConsumers = 1
        subscriptionDurable = false
        autoStartup = false
        connectionFactoryBean = "jmsConnectionFactory"
        messageSelector = null
        cacheLevel = DefaultMessageListenerContainer.CACHE_SESSION
    }
}
adapters {
    standard {
        messageConverter = new SimpleMessageConverter()
        persistenceInterceptorBean = 'persistenceInterceptor'
    }
}

The details aren’t important. The point is to illustrate the syntax.

Overriding defaults

This default config gets merged with the application config under the jms key (e.g. grailsApplication.config.jms). So to override the standard container to use a different connection factory we would have the following in our Config.groovy

jms {
    containers {
        standard {
            connectionFactoryBean = "someOtherJmsConnectionFactory"
        }
    }
}

Because Config.groovy is environment aware, we can also do things like

environments {
    development {
        jms.containers.standard.connectionFactoryBean = "someOtherJmsConnectionFactory"
    }
    test {
        jms.containers.standard.connectionFactoryBean = "testJmsConnectionFactory"
    }
}

You could even change the class of the default container definition.

jms {
    containers {
        standard {
            meta {
                clazz = SomeOtherListenerContainer
            }
        }
    }
}

Additional Beans

This mechanism also supports having more than one container type

jms {
    containers {
        other {
            meta {
                parentBean = "standardJmsListenerContainer"
            }
            connectionFactoryBean = "otherJmsConnectionFactory"
        }
    }
}

This creates a new container type called other that inherits all of the configuration from the standard container, but overrides the connection factory.

You would then use this container by specifying the container on the listener.

import grails.plugin.jms.Subscriber

class ListeningService {
    
    @Subscriber(container = "other")
    void interestingStuff(payload) {
        
    }
    
}

The Point

The point of this article is not specifically to talk about the JMS plugin. This approach to bean configuration seems to work quite well when users need access to the underlying beans in an optional manner. This may be an approach that other plugin authors might want to adopt.

Using Grails's JSON support with HTTPBuilder

Thu, 25 Feb 2010 13:01:00 +1100

I am currently working on a set of JSON over HTTP web services APIs between Grails applications. Producing JSON content in Grails applications is ridiculously trivial, but the story on consuming content is not so clear.

I am using Tom Nichol’s HTTPBuilder for consumption. It’s a great library, but does take a little getting used to. Fortunately, the documentation is excellent.

HTTPBuilder ships with JSON support based on Andres Almiray’s json-lib. That works fine, but I was worried about a potential impedance mismatch between json-lib’s encoding/decoding and Grails’.

Here’s how I configured HTTPBuilder to use Grails’ JSON bits for encoding/decoding JSON data…

import groovyx.net.http.HTTPBuilder
import groovyx.net.http.ParserRegistry
import groovyx.net.http.ContentType.JSON

import org.apache.http.entity.EntityTemplate
import org.apache.http.entity.ContentProducer
import org.apache.http.message.BasicHeader

// create a builder instance
def builder = new HTTPBuilder()

// the closure that takes a HttpServletResponse and returns an object
def jsonParser = { response ->
    grails.converters.JSON.parse(new InputStreamReader(response.entity.content, ParserRegistry.getCharset(response)))
}

// the closure that takes an object and returns an org.apache.http.HttpEntity
def jsonEncoder = { value ->
    def json = value instanceof Closure ? new grails.web.JSONBuilder().build(value) : new grails.converters.JSON(value)
    def producer = [writeTo: { OutputStream out -> out.withWriter { json.render(it) } }] as ContentProducer
    def entity = new EntityTemplate(producer)
    entity.contentType = new BasicHeader("Content-Type", JSON.toString())
    entity
}

// for each JSON content type, install the handler
JSON.contentTypeStrings.each {
    builder.parser."$it" = jsonParser
    builder.encoder."$it" = jsonEncoder
}

Note that you have to configure each created HTTPBuilder instance.

Here is some contrived example usage. We are calling a JSON “mirror” service that simply just returns the JSON it was sent.


import grails.plugin.spock.*

import groovyx.net.http.Method.POST
import groovyx.net.http.ContentType.JSON

class HttpBuilderWithGrailsJsonSpec extends UnitSpec {

    void "test it all works like it should"() {
        given: "a configured HTTP builder"
        def builder = new HTTPBuilder("http://jsonmirror.org")
        // configure the builder as per above
        
        when: "I post '{a: 1}' to the JSON mirror service"
        def requestMethod = POST
        def responseContentType = JSON
        def result = builder.request(requestMethod, responseContentType) {
            def requestContentType = JSON
            send(requestContentType) {
                a = 1
            }
        }
        
        then: "I get the JSON '{a: 1}' returned"
        result.a == 1
    }
}

LD.

Gr8Conf EU, now with more me

In response to Rob's post on functional testing.

Geb Modules and isDisplayed()

Using Grails tags where you can't use Grails tags

Always developing Grails apps with https and testing against the WAR

Always support https

Always functionally testing with a WAR

Functional tests and SSL (trust)

Why bother?

Decorating Constructors with Groovy

Spock's @AutoCleanup feature

spock.lang.AutoCleanup

Customizing how cleanup is performed

Cleaning up multiple objects

Handling of exceptions during cleanup

Disabling Grails plugin upgrade confirmation

Spock's new matching support

Custom Matchers

Summary

Getting more out of Property Override Configuration

Type Conversion

Your own beans

Summary

Painless Page Identification with Geb & Grails

Geb and Page Identification

Grails and Conventions

Action Page Objects

Geb and Inheritance (and Groovy)

Summary

Annotation Driven Extensions With Spock

Annotation Driven

The Annotation

The Extension

Listening In

In Action

The Real World

Summary

Proposal: Grails Plugin Collective

The Problem Being Addressed

The Proposed Solution

Goals and Aims

Relationship with VMWare and certification

Procedures and Principles

Initial Membership

Putting the Artefact API to work in your Grails app

What is it?

Why use it?

An example use case

The ProductHandler

A non artefact solution

Creating a ProductHandler artefact

Putting it together

Being more conventional

Summary

Forwarding/Chaining and models in Grails

Why use model instead of params?

Custom Grails Test Types/Phases

Test Phases

Mimicking standard phases

Test Types

Pre and post test type handlers

Types in integration or functional phases

Running your phase/type

Not having your type run by default

Why isn’t this in the manual?

Grails, WebTest and JQuery.

Scoped Services & Proxies in Grails

A shopping cart as a service

Using proxies to deal with scope differences

Some notes on Grails 1.3 improvements

Testing and scoped services

Why use scoped services and proxies?

Configuration based Spring bean definition with Grails.

A little bit about Grails JMS

Config based bean definitions

Overriding defaults

Additional Beans

The Point

Using Grails's JSON support with HTTPBuilder

The `ProductHandler`

Creating a `ProductHandler` artefact