Spring AOP with Groovy beans

A real use case for refreshable beans

As much fun as the banking application illustrated in this section is, few companies will allow you to deploy source code into production and then edit it while the system is running. So when would you actually use this capability?

Some problems only occur when a system is under load. Think of a refreshable bean as an adaptable probe that can be inserted into a Spring-based system by a serverside developer in a controlled fashion. You have the freedom to do more than just change a log level or some other property (which you could in principle do with JMX, the Java Management Extensions). You can change what the probe is doing in real time and diagnose what’s actually going on.

Dierk Koenig, lead author of Groovy in Action (Manning, 2007), calls this pattern “keyhole surgery.” It’s used as a minimally invasive procedure when you don’t know what you’re going to find when you go in.9

Before discussing the other Spring capability restricted to beans from dynamic languages, namely inline scripted beans, let me introduce another idea. One of the great features of Spring is that it provides a convenient infrastructure for aspect-oriented programming. I want to discuss what that means and how to use Groovy to implement an aspect.9

7.3Spring AOP with Groovy beans

Many of Spring’s capabilities are implemented using aspect-oriented programming (AOP). Spring provides the infrastructure for developing aspects. The interesting part is that aspects can be written as easily in Groovy as in Java.

AOP is a big subject, but I can summarize a few of the key features here.10 Aspects are designed to handle crosscutting concerns, which are features that apply to many different locations. Examples of crosscutting concerns include logging, security, and transactions. Each of them needs to be applied at multiple locations in a system, which results in considerable duplication, as well as tangling of different kinds of functionality in the same feature.

Crosscutting concerns are written as methods, known as advice. The next issue is where to apply the advice. The generic term for all available locations where advice can be applied is joinpoints. The set of selected joinpoints for a given aspect is known as a pointcut. The combination of an advice and a pointcut is what defines an aspect.

The sample application for this section and the next is shown in figure 7.4.

9Check out Dierk’s presentation “Seven Groovy Usage Patterns for Java Developers” on www.slideshare.net for more details.

10A complete discussion of AOP can be found in AspectJ in Action, 2nd edition (Manning, 2009), by Ramnivas Laddad, www.mannin10g.com/laddad2/.

www.it-ebooks.info

Figure 7.4 Spring AOP in action. ChangeLogger is a Java aspect that logs a message before each set method. UpdateReporter does the same in Groovy but reports on existing values. The GroovyAspect is an inline scripted bean defined inside the configuration file.

The following listing shows an example of an aspect, using Spring annotations, written in Java. This aspect is applied whenever a set method is about to be called, and it logs which method is being invoked and what the new value will be.

Listing 7.14 A Java aspect that logs changes to properties

package mjg.aspects;

import java.util.logging.Logger;

import org.aspectj.lang.JoinPoint;

import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before;

@Aspect

public class ChangeLogger {

private Logger log = Logger.getLogger( ChangeLogger.class.getName());

@Before("execution(void set*(*))") public void trackChange(JoinPoint jp) {

String method = jp.getSignature().getName(); Object newValue = jp.getArgs()[0]; log.info(method + " about to change to " +

newValue + " on " + jp.getTarget());

}

}

The @Aspect annotation tells Spring this is an aspect. The @Before annotation defines the pointcut using AspectJ pointcut language.11 This particular pointcut applies at all methods that begin with the letters set that take a single argument and return void. The trackChange method is the advice. The JoinPoint argument is supplied by Spring when the aspect is called. It provides context for the execution. In this case,

11The documentation for AspectJ is hosted with Eclipse, of all places. See http://www.eclipse.org/aspectj/ for details.

www.it-ebooks.info

the JoinPoint has methods to retrieve the signature of the method being advised, as well as the arguments supplied to the method and the target object.

To demonstrate this aspect in action, I need to configure Spring to apply the aspect, and I need an object to advise. The latter is easy enough. The next listing shows a simple class with three properties.

Listing 7.15 A simple POJO with three set methods

package mjg;

public class POJO { private String one; private int two; private double three;

public String getOne() { return one; }

public void setOne(String one) { this.one = one; }

public int getTwo() { return two; }

public void setTwo(int two) { this.two = two; }

public double getThree() { return three; }

public void setThree(double three) { this.three = three; }

@Override

public String toString() {

return "POJO [one=" + one + ", two=" + two + ", three=" + three + "]";

}

}

The class is called POJO, and it has three properties, called one, two, and three. Each has a getter and a setter. The aspect will run before each of the set methods.

Spring’s AOP infrastructure has some restrictions compared to full AOP solutions. Spring restricts pointcuts to only public method boundaries on Spring-managed beans. I therefore need to add the POJO bean to Spring’s configuration file. I also need to tell Spring to recognize the @Aspect annotation and to generate the needed proxy. The resulting bean configuration file is presented in the following listing.

Listing 7.16 The Spring bean configuration file for AOP

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

... namespace declarations elided ... >

<aop:aspectj-autoproxy />

<bean id="tracker" class="mjg.aspects.ChangeLogger" />

<bean id="pojo" class="mjg.POJO" p:one="1" p:two="2" p:three="3"/> </beans>

The aop namespace provides the <aspect-autoproxy> element, which tells Spring to generate proxies for all classes annotated with @Aspect. The tracker bean is the Java aspect shown previously. The pojo bean is the POJO class just discussed.

www.it-ebooks.info

Now I need to call the set methods in order to see the aspect in action. The next listing shows a test case based on JUnit 4 that uses Spring’s JUnit 4 test runner, which caches the application context in between tests.

Listing 7.17 A JUnit 4 test case to exercise the POJO

package mjg;

import static org.junit.Assert.*;

import org.junit.Test;

import org.junit.runner.RunWith;

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.test.context.ContextConfiguration;

import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@ContextConfiguration("classpath:applicationContext.xml")

@RunWith(SpringJUnit4ClassRunner.class) public class POJOTest {

@Autowired private POJO pojo;

@Test

public void callSetters() { pojo.setOne("one"); pojo.setTwo(22); pojo.setThree(333.0); assertEquals("one", pojo.getOne()); assertEquals(22, pojo.getTwo());

assertEquals(333.0, pojo.getThree(),0.0001);

}

}

Spring injects an instance of the POJO into the test and executes the test, which simply calls the three setters and checks that they work properly. The interesting part is in the console output, which shows the aspect in play:

INFO: setOne about to change to one on POJO [one=1, two=2, three=3.0] INFO: setTwo about to change to 22 on POJO [one=one, two=2, three=3.0]

INFO: setThree about to change to 333.0 on POJO [one=one, two=22, three=3.0]

The aspect reports the name of each set method and its argument when it’s called. Everything works as advertised.

There’s one issue, though. What if you want to know the current value of each property before the setter changes it? There’s no obvious way to find out. The joinpoint gives access to the target, and I know that a set method is being called, but while I know conceptually that for every setter there’s a getter, figuring out how to invoke it isn’t trivial. Determining the proper get method could probably be done with a combination of reflection and string manipulation, but there’s work involved.

At least, there’s work involved unless I appeal to Groovy. I can do everything I just described in a handful of lines of Groovy, as the next listing demonstrates.

www.it-ebooks.info

Listing 7.18 A Groovy aspect for printing property values before they are changed

package mjg.aspects

import java.util.logging.Logger

import org.aspectj.lang.JoinPoint

import org.aspectj.lang.annotation.Aspect import org.aspectj.lang.annotation.Before

@Aspect

class UpdateReporter {

Logger log = Logger.getLogger(UpdateReporter.class.name)

@Before("execution(void set*(*))") void reportOnSet(JoinPoint jp) {

String method = jp.signature.name String base = method – 'set'

String property = base[0].toLowerCase() + base[1..-1] def current = jp.target."$property"

log.info "About to change $property from $current to ${jp.args[0]}"

}

}

The UpdateReporter class is written in Groovy. It has the @Aspect and @Before annotations exactly as the Java aspect did. The method being invoked is computed the same way the Java aspect did, with the only minor difference being that Groovy accesses the signature and name properties rather than explicitly invoking the associated getSignature and getName methods. That’s a case of foreshadowing, actually, because it means that all I really need to do is to figure out the name of the property.

The property is found by taking the name of the set method, subtracting out the letters set, and converting the result to standard property syntax. Now that I have the name of the property, I just need to access it from the target, which is done on the next line. I used a Groovy string to make sure that the property is evaluated. The result is that in three lines of Groovy I now know what the original value of the property is. All that remains is to log it to standard output.

To run this aspect I just added a corresponding bean to the configuration file:

<bean id="updater" class="mjg.aspects.UpdateReporter" />

Now if I run the same test case the output is as shown here:

INFO: About to change one from 1 to one

INFO: setOne about to change to one on POJO [one=1, two=2, three=3.0] INFO: About to change two from 2 to 22

INFO: setTwo about to change to 22 on POJO [one=one, two=2, three=3.0] INFO: About to change three from 3.0 to 333.0

INFO: setThree about to change to 333.0 on POJO [one=one, two=22, three=3.0]

Both the Groovy aspect and the Java aspect are executing on the set methods of the POJO. The advantage of the Groovy aspect is that it’s easily able to determine the existing value of the property before changing it.

www.it-ebooks.info

Life isn’t quite as simple as I’m describing it. The string manipulation that processed the set method determined a property name. If the property doesn’t actually exist (or, rather, the get method doesn’t exist), accessing it isn’t going to work. Still, asking that each setter has a corresponding getter doesn’t seem to be too much to expect, especially because Groovy POGOs do that automatically.

To finish this section, listing 7.19 shows an aspect added to the banking example from the beginning of this chapter, tracing methods in the Account class. Because Account is a POGO, I don’t have explicit setter methods. I don’t necessarily want to track all the getters, either, because one of them is getMetaClass, and that’s not a business method.

One way around that is to use a Java interface implemented by the POGO. Instead, here I’m going to use explicit pointcuts and put them together.

Here’s the complete AccountAspect listing with the pointcuts and advice.

Listing 7.19 An aspect tracking methods in the Account POGO

import java.util.logging.Logger

import org.aspectj.lang.JoinPoint

import org.aspectj.lang.annotation.Aspect import org.aspectj.lang.annotation.Before import org.aspectj.lang.annotation.Pointcut

@Aspect

class AccountAspect {

Logger log = Logger.getLogger(AccountAspect.class.name)

@Pointcut("execution(* mjg..Account.deposit(*))") void deposits() {}

@Pointcut("execution(* mjg..Account.withdraw(*))") void withdrawals() {}

@Pointcut("execution(* mjg..Account.getBalance())") void balances() {}

@Before("balances() || deposits() || withdrawals()") void audit(JoinPoint jp) {

String method = jp.signature.name

log.info("$method called with ${jp.args} on ${jp.target}")

}

}

The @Pointcut annotation is how you create a named pointcut. The name is set by the name of the method on which it’s applied. The three pointcuts here match the deposit, withdraw, and getBalance methods in the Account class. The @Before advice combines them using an or expression and logs the method calls. When running the AccountSpec tests, the (truncated) output is similar to this:

Jun 28, 2013 12:03:29 PM

INFO: getBalance called with [] on mjg.spring.entities.Account(id:4, balance:100.0)

Jun 28, 2013 12:03:29 PM

www.it-ebooks.info