To overcome this, we use a pattern which I’ll call the “Domain Test Values Class”,  the purpose of which is to provide values used in the testing of a domain in a way which improves understanding of test code by increasing readability and adding meaning to values.

Natural language in tests

Mockito and Hamcrest greatly improve test readability by allowing you write tests like this:

AccountService accountService = mock(AccountService.class);
given(accountService.getBalance(1234567)).willReturn(100.0);

double remainingBalance = accountController.withdraw(1234567, 100.0);

assertThat(remainingBalance, is(0.0));
verify(accountService, never()).markOverdrawn();

So in these few lines we can see what’s mocked, that the remaining balance should be 0.0 and that markOverdrawn() should never be called.

Removing the magic numbers

We’re still lacking some clarity because of those magic numbers and it’s always good practice to replace them with constants:

final long accountNumber = 1234567L;
final double startingBalance = 100.0;
final double withdrawalAmount = startingBalance;

AccountService accountService = mock(AccountService.class);
given(accountService.getBalance(accountNumber)).willReturn(startingBalance);

double remainingBalance = accountController.withdraw(accountNumber, withdrawalAmount);

assertThat(remainingBalance, is(0.0));
verify(accountService, never()).markOverdrawn();

Now it’s more obvious from the code what the numbers mean, but it’s still not ideal, we don’t know if it matters that the account number is 1234567. Or if the starting balance has to be 100. Are we right to assume that 0.0 means that the account is empty?

Adding meaning

With a little renaming the test not only becomes more readable, but it starts showing more intent:

final long anAccountNumber = 1234567L;
final double aCreditBalance = 100.0;
final double aZeroBalace = 0.0;

AccountService accountService = mock(AccountService.class);
given(accountService.getBalance(anAccountNumber)).willReturn(aCreditBalance);

double remainingBalance = accountController.withdraw(anAccountNumber, aCreditBalance);

assertThat(remainingBalance, is(aZeroBalance));
verify(accountService, never()).markOverdrawn();

Now simply by choosing some good names the test is very easily understood, so let’s apply this more generally:

The domain test values class

It’s not hard to see that some of the values in the example above will be required in other tests in the account domain, so instead of putting them at the top of the method or as constants in just one test, let’s statically import them and create an AccountDomainTestValues class:

public class AccountDomainTestValues {
    /**A constant test value*/
    public static final long AN_ACCOUNT_NUMBER = anyAccountNumber();
    /**A constant test value*/
    public static final double A_CREDIT = anyCredit();
    /**A simple constant*/
    public static final double ZERO_BALANCE = 0.0;
    /**A generated value*/
    public static final long anyAccountNumber() {
        //randomly generate an account number
    }

    /**A generated value*/
    public static final long anyCredit() {
        //randomly generate a credit value
    }
}

As well as constants, the class also provides methods for generating values. Notice the naming convention – constants are prefixed with “a” or “an” while methods generating values use “any” – this adds intent to the value:

• “any”: the actual value is not important to the test
• “a”: the value is fixed and so should be considered important and can be used more than once to mean the same thing during a test

For example:

import static com.manbuildswebsite.AccountDomainTestValues.*;
...

accountService.deposit(AN_ACCOUNT_NUMBER, anyCredit());

assertThat(accountService.isOverdrawn(AN_ACCOUNT_NUMBER), is(false));

Using the “any” methods to populate the constant fields exercises a larger range of values than would otherwise be the case; programmers tend to stick to numbers like 1 or 123, and while randomly generating numbers is not a substitute for testing edge cases, it does ensure a range of real-life values are tested.

We’ve found that by using the domain test values class pattern we’ve improved the readability, and so the understanding and maintainability, of our test code for very little effort.

Disclaimer…

This pattern, or something like it, may well have been catalogued somewhere already, though if it has I’m yet to find it, so I present it here in the hope that it either helps others or that someone will point me to a published version of it!

© 2010 Dave Bower/Man Builds Website

Much like my favicon woes my initial attempt to redirect to a primary domain (a .com without the “www” prefix) had some unexpected consequences when deployed to a live server on CloudFoundry – I started getting warnings that my site had gone down!

In this post I’ll hopefully save you the panic of CloudFoundry telling you that your site’s not responding when you try to rationalise your domain names!

www? It’s so last century

Here’s the problem: you’ve got your domain, let’s say it’s lourish.com and you want to set up your site so that if people go to http://www.lourish.com, they’re immediately redirected to http://lourish.com, dropping the www.

If you’ve also been on a spending spree and bought the .org, .co.uk and a host of other domains all of which just point back to your .com site then, without a redirect you’ll find search engines can list each domain separately, ruining your search ranking.

(Not) Fixing it with a Filter

We’re talking Grails here (though the principles are the same in Java too) so creating a filter to make the redirect work is simple stuff. Here’s a snippet of code from my filter class:

    def filters = {
        redirectToDotCom(uri: '/**') {
            before = {
                if(request.serverName != "lourish.com") {
                    def reqUrl = request.requestURL
                    def redirectTo = reqUrl.toString()
                        .replace(request.serverName, "lourish.com")
                    redirect(url: redirectTo)
                    return false
                }
            }
        }
...

So what we do is

1. Intercept all requests (uri: '/**'/)
2. Check the server name
3. If it’s not the primary .com address (lourish.com), replace the server name in the incoming request with the .com server name
4. Perform the redirect

Simple enough and it works in most cases – it doesn’t cope with upper case or request parameters, but then if the redirect works, parameters should never be generated!

Confusing CloudFoundry

If you’re deploying to CloudFoundry you’ll find that this simple filter causes big problems.

CloudFoundry has a great little monitoring feature which will check that your site’s up by not only checking your Apache server on localhost port 80 but also your tcserver’s servlet manager on localhost port 8080 – testing for a 200 status.

But take a look at what that filter’s doing, it’s redirecting absolutely everything to our .com address. This is ok for the Apache test – the 302 leads to a 200 eventually, but it also affects the call to tcserver on localhost:8080 which should check the management console, but we’re redirecting to .com:8080 and that port’s blocked!

So the filter causes a false reading on the monitoring tool and potentially unexpected problems, like the app being restarted to “fix” the problem!

Fixing the Filter

To fix this we could test the port but the solution I chose was simply to add a few “pass-through” urls to the filter:

    static final List ALLOWED_SERVER_NAMES = ["lourish.com", "localhost", "127.0.0.1"]
    static isLive = Environment.current == Environment.PRODUCTION

    def filters = {
        redirectToDotCom(uri: '/**') {
            before = {
                if (isLive
                        && !ALLOWED_SERVER_NAMES.contains(request.serverName)){
                    def reqUrl = request.requestURL
                    def redirectTo = reqUrl.toString()
                        .replace(request.serverName, "lourish.com")
                    redirect(url: redirectTo)
                    return false
                }
            }
        }

I’ve added ALLOWED_SERVER_NAMES which contains the host names which won’t be not redirected and I’ve also added an isLive check to let me test on my beta and local servers without constantly being redirected to the live site!

So that’s how to redirect to one address in a Grails app and still keep CloudFoundry happy!

Exception in thread "main" 
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: 
Communications link failure

Last packet sent to the server was 0 ms ago.

I’d already set up the driver with what I understood to be the correct reconnection properties – autoReconnectForPools=true and a validation query – in my Grails app:

dataSource {
    dbCreate = "update"
    driverClassName = "com.mysql.jdbc.Driver"
    username = "lourishbeta"
    password = "lourishbeta"
    url = "jdbc:mysql://${System.getProperty("dbHostName",
            "localhost")}/beta?autoReconnectForPools=true"
    properties {
        validationQuery = "select 1"
        maxActive = 150
    }
}

I initially thought it must be something to do with the (generally very reliable) CloudFoundry dropping the connection, but eventually I came upon this enormous thread on the MySQL forums which, in a very, very roundabout way gave the solution:

Use 127.0.0.1 instead of localhost.

So now my datasource looks like this:

dataSource {
    dbCreate = "update"
    driverClassName = "com.mysql.jdbc.Driver"
    username = "lourishbeta"
    password = "lourishbeta"
    url = "jdbc:mysql://${System.getProperty("dbHostName",
            "127.0.0.1")}/beta?autoReconnectForPools=true"
    properties {
        validationQuery = "select 1"
        maxActive = 150
    }
}

And the MySQL connection has been up for over 2 weeks. Phew!

Odds on you’ve installed the Spring Security plugin and forgotten to give permission to the favicon file in the root and the result is that on login Spring Security redirects you to the first restricted item that was requested by the browser – the favicon.

The solution? Easy, set the favicon path to IS_AUTHENTICATED_ANONYMOUSLY in your SecurityConfig.groovy (or database):

controllerAnnotationStaticRules = [
    ...
    '/favicon.ico' : ['IS_AUTHENTICATED_ANONYMOUSLY'],
    ...
]

Brief Background

For those who are unaware of the UI-Performance plugin, it provides a set of easy-to-implement performance improvements for Web applications, based on the “14 rules” from Steve Souders of Yahoo!. These involve such things as compressing content by zipping, setting expires headers, moving Javascript to the bottom of pages and more.

Easy to Implement

The plugin is extraordinarily easy to use in an existing Web app and I was up and running within a couple of hours of downloading – with dramatic performance improvements to my page load times.

Extending to Embedded CSS Font Files

As with many current websites I’ve been using embedded fonts and it wasn’t immediately obvious how to get the UI-Performance plugin to configure font files for caching, however a bit of experimentation showed that it was, in fact, dead easy!

There is a configuration property for the file extensions the plugin will set up for caching and all you need do is add the font suffixes “woff”, “ttf”, “svg” and “eot”, so that your Config.groovy has the line:


uiperformance.imageExtensions=['gif', 'jpg', 'png', 'woff', 'ttf', 'svg', 'eot']


And that’s it! The same principle applies to any other file types you may be referencing in your CSS (whatever they may be!).

I think the release notes for Grails 1.3.x have been unusually poor so this post has the issues I’ve encountered in the hope that you won’t go quite as mad as I have. I’ll keep it updated if I find more problems.

Controller defaultAction must now be static

Not much more to say, but if like me you’ve been doing this in your controllers:

    def defaultAction = "open"

you’ll need to do this instead:

    static defaultAction = "open"

Otherwise you’ll get a tomcat 404 error saying that “resource() is not available”

Missing dependencies

Now I can't say if this was me doing something wrong or a problem with the upgrade process, but when I tried to run my app for the first time I got all sorts of dependency problems. I don't use Maven, or any Maven repos (in fact I don't like Maven, but that's another post for another day) but I was getting lots of Maven output suggesting lookups for every dependency were being made to a remote repo.

I eventually solved the problem by adding grailsCentral() to my repositories in the build.config, quite why it wasn't there in the first place I don't know:

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.project.dependency.resolution = {

    inherits("global") {
    }
    log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()
    }
    dependencies {
        runtime 'mysql:mysql-connector-java:5.1.5'
    }
}

My tag looked like this:

<g:datePicker name="myDate"
    value="${myBean.aDate}"
    precision="day"
    years="${[2009, 2010, 2011]}"
    noSelection="${['':'--']}"/>

Whenever myBean.aDate was null the tag still displayed today’s date and no matter how I read the datePicker docs there seemed to be no solution, that is until I happened upon a mailing list post which showed a “default” attribute:

<g:datePicker name="myDate"
    value="${myBean.aDate}"
    precision="day"
    years="${[2009, 2010, 2011]}"
    noSelection="${['':'--']}"
    default="none"/>

The addition of “default=none” stops the tag showing today’s date and instead reverts to the noSelection value as I had originally expected. I have no idea what other values this “default” attribute can take, or where the code that reads it is in the Grails source (a search for datePicker in the source yielded nothing useful) so I can’t say anything more about it!

As soon as the Grails JIRA is back up (under maintenance at the moment, apparently) I’ll raise a bug on the docs.

Design

Below is an overview of the system I’ll be building.

Design Overview

The EmailService handles the synchronous part of sending (queueing, adapting, formatting), the SendMailQueue is ActiveMQ via JMS and the SendMailService handles the background sending of the email using the Grails Mail plugin connecting to Gmail over SMTPS/SSL.

Setup

You will need Grails 1.2.x or newer and these plugins:

• JMS
• ActiveMQ
• Mail

You will also need a Gmail account if you want to reproduce this entire tutorial. I set up a premium account but the configuration should be the same for a free account.

Configuration

Most of the effort is in getting the configuration right, and it’s not really any work at all as I’ve worked it out for you! We just need to set up an ActiveMQ Spring bean as our JMS provider and configure the mail plugin to use a Gmail account.

Spring Configuration

If you don’t have an external ActiveMQ server you’ll need to set up a local one by adding a connection factory bean. In the following example I also set up a connection pool to improve performance (otherwise there’s a performance hit on every message sent). Just add this to Resources.groovy:

beans = {
    jmsConnectionFactory(org.apache.activemq.pool.PooledConnectionFactory){bean ->
        bean.destroyMethod ="stop"
        connectionFactory(org.apache.activemq.ActiveMQConnectionFactory) {
            brokerURL = "tcp://localhost:61616"
        }
    }
}

JavaMail settings for Gmail

There is a huge amount of conflicting information about how JavaMail should be configured for Gmail, it’s an interesting case as it requires an SSL connection, rather than a plain SMTP one. However, I can guarantee that the following settings work for the Grails Mail plugin (and therefore also for Spring’s SimpleMailMessage) with a Gmail account.

In Config.groovy add the following (and replace the username and password with your own!):

grails.mail.host = "smtp.gmail.com"
grails.mail.from = "address@mydomain.com"
grails.mail.port = "465"
grails.mail.username = "user@mydomain.com"
grails.mail.password = "mypassword"
grails.mail.props = ["mail.smtp.auth": "true",
        "mail.smtp.socketFactory.port": "465",
        "mail.smtp.socketFactory.class": "javax.net.ssl.SSLSocketFactory",
        "mail.smtp.socketFactory.fallback": "false",
        "mail.smtp.starttls.enable": "true",
        "mail.debug": "true"]

The last item in the props setting – mail.debug – provides some useful logging, more on that below, but you can remove it when you have it working.

Of course, it’s unlikely that you’ll have the same mail server for dev, test and prod so you can set up different environment configurations:

environments {
    production {
        grails.mail.host = "smtp.gmail.com"
        grails.mail.port = "465"
        grails.mail.username = "user@mydomain.com"
        grails.mail.password = "mypassword"
        grails.mail.props = ["mail.smtp.auth": "true",
                "mail.smtp.socketFactory.port": "465",
                "mail.smtp.socketFactory.class": "javax.net.ssl.SSLSocketFactory",
                "mail.smtp.socketFactory.fallback": "false",
                "mail.smtp.starttls.enable": "true",
                "mail.debug": "true"]

    }
    development {
        grails.mail.host = "smtp.gmail.com"
        grails.mail.port = "465"
        grails.mail.username = "devuser@mydevdomain.com"
        grails.mail.password = "mydevpassword"
        grails.mail.props = ["mail.smtp.auth": "true",
                "mail.smtp.socketFactory.port": "465",
                "mail.smtp.socketFactory.class": "javax.net.ssl.SSLSocketFactory",
                "mail.smtp.socketFactory.fallback": "false",
                "mail.smtp.starttls.enable": "true",
                "mail.debug": "true"]
    }
}

You may be tempted to add the config like this:

development {
        grails {
            mail {
                host = "smtp.gmail.com"
                port = ...

Don’t! By defining a “grails” closure you will clear all previously defined settings for the “grails” key!

Implementing the Services

We’re almost finished and we haven’t yet written a line of real code! Let’s start with the EmailService which will help us queue the messages:

EmailService

Let’s create a new non-transactional service named EmailService, in this service we could add any request processing, security checks and adapt the request for queuing.

package lourish

class EmailService {

    boolean transactional = false

    def sendEmail(attrs) {
        sendJMSMessage("sendMail",
                [to: attrs.to,
                 from: attrs.from,
                 subject: attrs.subject,
                 view: attrs.view,
                 model: attrs.model])
    }
}

This service method is just one call to sendJMSMessage (a meta-method added to all services and controllers by the JMS plugin). The first argument is the queue name we’re sending to and the second is the JMS message itself, in this case a map defining the email to send.

Make sure that everything you send over an ActiveMQ queue is a primitive type, map or list – it ought to be possible to send serializable objects but in my experience it simply doesn’t work!

SendMailService

The JMS plugin is set up to deliver messages to any service “exposed” to JMS which has the same name as the queue the message is on. So in the EmailService we send the message on the sendMail queue so the JMS plugin will try to find a service named SendMailService and call its onMessage method:

package lourish

class SendMailService {
    boolean transactional = false

    //Tell the JMS plugin that this is a message endpoint
    static expose = ['jms']

    //The Mail plugin service
    def mailService

    def onMessage(emailMessage) {
        try {
            mailService.sendMail {
                to emailMessage.to
                from emailMessage.from
                subject emailMessage.subject
                body(view: emailMessage.view, model: emailMessage.model)

            }
        } catch (Exception e) {
            log.error("Failed to send email ${emailMessage}", e)
        }
        //Return null to avoid poison messages
        return null
    }
}

Notice that the onMessage method is returning null – this is important as it tells the MessageListenerAdapter that the method has run successfully. If you return anything else it will be assumed it’s a retry message and you could end up with a poison messaged in your queue.

Also note that the “mailService” bean is set up by the Mail plugin and there are more details in the plugin documentation about how it works.

HTML Templates

As we’re sending HTML emails we need to create a template GSP for the message body as defined in the “view” parameter of the JMS message. Create the following helloWorld.gsp template in grails-app/views/emails:

<%@ page contentType="text/html" %>
<html>
<body><h1>${greeting}</h1></body>
</html>

I’d recommend a good read of the Mail plugin and Spring JMS docs for full details. Bear in mind that the email templates don’t support sitemesh layouts.

Sending a Mail

That’s the services created and the system configured so we can try it out.

An Example Controller

Here’s an example of a controller to send a test email to demonstrate how the whole thing works:

package lourish

class SendMailController {
    //Our email queuing service
    def emailService

    def index = {
        try {
            emailService.send(to: "myemail@emailaddress.com",
                from: "me@gmail.com",
                subject: "Test HTML mail using JMS, ActiveMQ, and the Grails Mail plugin",
                model: [greeting: "Hello World!"],
                view: "/emails/helloWorld")

        } catch (Exception e) {
            log.error("${e}", e)
            flash.message = "Mail not sent: ${e}"
            return
        }
        flash.message = "Mail sent"
    }
}

and a corresponding GSP in views/sendMail/index.gsp:

<%@ page contentType="text/html;charset=UTF-8" %>
<html>
<head><title>Mail Test</title></head>
<body>${flash.message}</body>
</html>

You can now run the app and browse to /sendMail to send an email.

Debug

When you run the app, you should not only receive an email but you should also see some logging from Java mail if you have the debug in. It will look a bit like this:

DEBUG: JavaMail version 1.4.1
DEBUG: not loading file: C:\java\jdk1.6.0_16\jre\lib\javamail.providers
DEBUG: java.io.FileNotFoundException: C:\java\jdk1.6.0_16\jre\lib\javamail.providers (The system cannot find the file specified)
DEBUG: !anyLoaded
DEBUG: not loading resource: /META-INF/javamail.providers
DEBUG: successfully loaded resource: /META-INF/javamail.default.providers
DEBUG: Tables of loaded providers
DEBUG: Providers Listed By Class Name: {com.sun.mail.smtp.SMTPSSLTransport=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc], com.sun.mail.smtp.SMTPTransport=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc], com.sun.mail.imap.IMAPSSLStore=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun Microsystems, Inc], com.sun.mail.pop3.POP3SSLStore=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun Microsystems, Inc], com.sun.mail.imap.IMAPStore=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc], com.sun.mail.pop3.POP3Store=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsystems, Inc]}
DEBUG: Providers Listed By Protocol: {imaps=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun Microsystems, Inc], imap=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc], smtps=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc], pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsystems, Inc], pop3s=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun Microsystems, Inc], smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]}
DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map
DEBUG: !anyLoaded
DEBUG: not loading resource: /META-INF/javamail.address.map
DEBUG: not loading file: C:\java\jdk1.6.0_16\jre\lib\javamail.address.map
DEBUG: java.io.FileNotFoundException: C:\java\jdk1.6.0_16\jre\lib\javamail.address.map (The system cannot find the file specified)

If it gets to this point and stops, it means that the mailService bean has initialised but sending the mail has failed because of some application issue before connecting to the remote mail server. Note that the exceptions in the logging above are benign if they’re at DEBUG level so don’t be confused by them, you’ll need to check your application logging for the real problem.

Running in a WAR

There is a bug in the Mail plugin which means that sending mail using templates fails when an application is packaged as a WAR and deployed in a container. The exception you’ll see is:

org.springframework.jms.listener.adapter.ListenerExecutionFailedException:
 Listener method 'onMessage' threw exception; nested exception is
  java.lang.NoClassDefFoundError: org/springframework/mock/web/MockHttpServletRequest

The problem is that the Mail plugin relies on the MockHttpServletRequest class in the spring test jar which is unavailable when running in a WAR, but present when using run-app. To resolve this issue it’s necessary to add the Spring Framework test jar, in my case $GRAILS_HOME/lib/org.springframework.test-3.0.0.RELEASE.jar, to your lib directory. It’s an ugly fix, but hopefully it will only be temporary.

Further Reading

I hope that I’ve provided a useful overview of queued email which is suitable for production Web applications. In most large companies the mail server is likely to be local so you probably won’t have to deal with Gmail, however the concepts remain the same.

For more information on the topics in this post also see:

• Grails Mail Plugin: http://www.grails.org/Mail+plugin
• Grails JMS Plugin: http://www.grails.org/JMS+Plugin
• Grails ActiveMQ Plugin: http://www.grails.org/ActiveMQ+Plugin
• Integrating ActiveMQ with Spring: http://activemq.apache.org/spring-support.html
• Spring JMS support: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jms.html

Building an Aspect Around Spring Security

In my last post I showed how to update the logged-in user domain object when using the Spring Security plugin – whenever the user domain object is updated the security context also needs to be  updated as the plugin caches the logged in user. A nice way to implement this cache refresh would be to annotate those methods which update the user domain object; given a UserService with an updateUser method, I want to be able to annotate that method so that the cached domain object is refreshed:

public class UserService {
    @UpdatesUser
    User updateUser(user) {
        println "updateUser"
    }
}

To implement this aspect I will follow these 5 steps:

1. Create the UpdatesUser annotation
2. Create a Spring bean for the ‘refreshAuthenticatedUser’ method which will perform the cache refresh
3. Write a pointcut to match the ‘join points’ where the user is updated (ie the annotated methods on which the aspect should be applied)
4. Mark up ‘refreshAuthenticatedUser’ with advice so it is called for annotated methods
5. Configure the Spring container to use the aspect

Aspects can be written in Groovy or Java but since this is a Grails post I’ll show a pure Groovy/Grails example using @AspectJ annotations

Creating the Annotation

The noteworthy thing about the annotation is that it needs to be retained at runtime. Otherwise it’s very simple and can live in the src/groovy directory:

package example

import java.lang.annotation.ElementType
import java.lang.annotation.Target
import java.lang.annotation.RetentionPolicy
import java.lang.annotation.Retention

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface UpdatesUser {
}

Creating a Spring Bean for the Aspect

Taking the code from my last post to refresh the user cache I can create an aspect using markup:

package example

import org.springframework.security.context.SecurityContextHolder
import org.springframework.security.providers.UsernamePasswordAuthenticationToken
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsUserImpl
import org.springframework.security.GrantedAuthorityImpl
import org.springframework.security.GrantedAuthority

@Aspect
@Component("refreshUserAspect")
public class RefreshUserAspect {

    public void refreshAuthenticatedUser(User user){
        GrantedAuthority[] auths = user.authorities.collect {
            new GrantedAuthorityImpl(it.authority)
        }
        def grailsUser = new GrailsUserImpl(
                user.username,
                "",
                user.enabled,
                true,
                true,
                true,
                auths,
                user)
        def authToken = new UsernamePasswordAuthenticationToken(grailsUser, "", auths)
        SecurityContextHolder.context.authentication = authToken
    }
}

So the only additions to the code are the annotations:

• @Aspect to allow the framework to auto-create this class as an aspect
• @Component tells the framework that this is a Spring bean with the name “refreshUserAspect”

Defining a Pointcut

The pointcut definition tells the framework when the refreshAuthenticatedUser method should be called, in this case it’s whenever the UpdatesUser annotation is present. The definition will live in the same class as the Aspect:

@Aspect
@Component("refreshUserAspect")
public class RefreshUserAspect {

    @Pointcut("@annotation(example.UpdatesUser)")
    public void userUpdatingOperation() {
    }

    public void refreshAuthenticatedUser(User user){
...
    }
}

The pointcut is just an annotated empty method and the UpdatesUser annotation is referenced by its fully qualified class name in the pointcut annotation.

Declaring the Advice

An advice declaration relates a pointcut to a method and in this case must also inject the user object into the method.

It looks like this:

    @AfterReturning(pointcut="example.RefreshUserAspect.userUpdatingOperation()",
            returning="user")
    public void refreshAuthenticatedUser(User user){
...
    }

It’s saying:

• @AfterReturning – call this method on successful execution of methods
• pointcut=”example.RefreshUserAspect.userUpdatingOperation” – attach this advice to methods matched by the pointcut defined on the userUpdatingOperation method of this class
• returning=”user” – use the return value of the matched method for the ‘user’ argument of this advice

Configuring the Spring Container

In order for Spring to find the @AspectJ annotated aspect it’s necessary to define an AnnotationAwareAspectJAutoProxyCreator. It shouldn’t be needed since Grails 1.2.x but Grails 1.2.1 has a few problems with its aspect support which I will discuss later.

Define the AnnotationAwareAspectJAutoProxyCreator in Resources.groovy:

import org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator
import example.aop.SimpleAspect

beans = {
    autoProxyCreator(AnnotationAwareAspectJAutoProxyCreator) {
        proxyTargetClass = true
    }
}

So the final Aspect looks like this:

package example

import org.springframework.security.context.SecurityContextHolder
import org.springframework.security.providers.UsernamePasswordAuthenticationToken
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsUserImpl
import org.springframework.security.GrantedAuthorityImpl
import org.springframework.security.GrantedAuthority

@Aspect
@Component("refreshUserAspect")
public class RefreshUserAspect {

    @Pointcut("@annotation(example.UpdatesUser)")
    public void userUpdatingOperation() {
    }

    @AfterReturning(pointcut="example.RefreshUserAspect.userUpdatingOperation()",
            returning="user")
    public void refreshAuthenticatedUser(User user){
        GrantedAuthority[] auths = user.authorities.collect {
            new GrantedAuthorityImpl(it.authority)
        }
        def grailsUser = new GrailsUserImpl(
                user.username,
                "",
                user.enabled,
                true,
                true,
                true,
                auths,
                user)
        def authToken = new UsernamePasswordAuthenticationToken(grailsUser, "", auths)
        SecurityContextHolder.context.authentication = authToken
    }
}

Now if the updateUser method in the UserService is annotated:

public class UserService {
    @UpdatesUser
    User updateUser(user) {
        println "updateUser"
    }
}

the spring security user object will be refreshed thanks to a call to the aspect’s @AfterReturning advice. Although this example is quite simple there’s not much more that is Grails-specific left to know when creating aspects.

Problems in Grails 1.2.1

There are a number of issues with aspect support in Grails 1.2.1 which make working with aspects difficult. Most should be resolved in the 1.2.2 release but I’ll mention some of them here since they make certain operations impossible.

Repeat calls to the same advice

Although the annotation-based pointcuts I’ve described here work perfectly, other types of pointcuts can cause problems. For example, defining a pointcut as:

@Pointcut("execution(* example.UserService.updateUser(..))")

should match the service method and call the advice just the same as the annotation, but what actually happens is that the advice is called more than once for every call to updateUser.

I haven’t tried all types of pointcut definition, but be aware that other types may suffer from this problem.

Service methods subject to advice cannot be edited on-the-fly

Another unfortunate problem is that if a service has a method which is subject to an aspect, changing that service in any way will cause it to be recompiled and future calls to that service method will fail with a CGLIB error when running the application in development (grails run-app):

java.lang.ClassCastException: example.SimpleService$$EnhancerByCGLIB$$735effdb cannot be cast to example.UserService

I’m not sure if this is likely to be fixed in the next version of grails or not.

@AspectJ annotated aspects are not auto-discovered

It should be possible to use beans with @AspectJ annotations without creating an AnnotationAwareAspectJAutoProxyCreator, however Grails doesn’t find the annotated classes so the auto-proxy creator must be manually defined in the Spring resources as described earlier in this post. This should be fixed in Grails 1.2.2.

The Future

I’ll update this post with more information after the next release of Grails, when hopefully some of the problems are resolved, until then I hope this serves as a useful example.

Stop Caching the User Domain Object

There are a couple of ways to solve this problem, the brute-force approach is to turn off caching of the domain object  so it’s reloaded on each call. Turning off user caching is simple in the latest version of the Spring Security plugin, just add this line to your SecurityConfig.groovy file:

cacheUsers = false

Refresh the Authentication Token

Of course there is a performance hit associated with turning off caching, so instead it’s much more useful to be able to refresh the domain object only when needed. This can be achieved using the same method as logging in a user when the password is not available, as described in my previous post:

import org.springframework.security.context.SecurityContextHolder
import org.springframework.security.providers.UsernamePasswordAuthenticationToken
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsUserImpl
import org.springframework.security.GrantedAuthority
import org.springframework.security.GrantedAuthorityImpl
...
    private def refreshUserPrincipal(username) {
        def user = User.findByUsername(username)
        GrantedAuthority[] auths = user.authorities.collect {
            new GrantedAuthorityImpl(it.authority)
        }
        def grailsUser = new GrailsUserImpl(
                user.username,
                "",
                true,
                true,
                true,
                true,
                auths,
                user)

        def authToken =  new UsernamePasswordAuthenticationToken(
                grailsUser, '', auths)
        SecurityContextHolder.context.authentication = authToken
    }

So by calling the refreshUserPrincipal method after making updates to the user’s domain object you can maintain the benefits of caching while continuing to use the authenticateService.userDomain object to read up-to-date properties of the user.

Update

Also see my post on AOP where I show how this update method can be extended using aspect oriented programming.