Exception verification using fault injection via AOP

November 13, 2011

A simple example is used to show how to use Aspect Oriented Programming to provide fault injection.

Intro

A few months ago I was looking at Java code and thinking there must be a better way to see if this will really work, if there are any issues in how the program would react to exceptional conditions.  I could write some unit tests or force some problems to see if the exception handling is correct and the log file output is really useful.  But is there another way?

I got a solution after a while of thinking: Insert faults.  Now how to do that in an easy and  maintainable way? Not a new idea of course. After doing a web search I found some interesting references.

Funny, today at work I was extending an application and one of the support objects was failing. Turned out to be an index out of bounds problem. The method had adequate exception handling but, of course, an index out of bounds scenario was not tested. In this case the problem would not occur in production (hmmm), but it definitely occurred during development, and was not handled correctly.

Exception Handling

There are many references of correct exception handling strategies and best practices.  However, when creating applications, the developer must still make critical creative decisions about how to handle an exception.    That decision may not be a wise one.  And even if it is, may later prove to have been very unwise since the system requirements and implementation may have changed due to maintenance or requirement evolution.

Testing Approaches

Using various testing methodologies a subsystem can be exhaustively tested for exception handling.  Yet, most testing methods require that the subsystems be isolated in some manner.   This, though very valuable, can give fatal false confidence that the system will behave in a predictable manner in responding to exceptional conditions.

The prime example of this is within the Unit Testing methodologies.  Since Unit Tests are tests of isolated components, they do not test actual exception handling in the live system.  A perfect component can still contribute to system failure when it is used incorrectly or uses other components incorrectly.    For example, a unit test can show that class X’s methods correctly handle and when necessary throw the perfect exception.   That means nothing if components that interact with X don’t correctly use those exceptions:  they swallow, mask, or mistakenly catch them when there is nothing they can do.

Thus, one needs to use Integration Testing to test assemblages of components.  But, we are still back with the same shortcoming as with Unit Testing. Thus we would next need various forms of system testing.  And, that system testing must be a White Box test.  A Black Box test wherein an interface is exercised with various inputs (such as in web test systems or by QA personnel), will not necessarily invoke the full internal API/SPI between components that could be part of a complicated call chain.  Why?  Because, the interface, such as a browser client, will have (we hope) the validation, security, and logging layers implemented so that by the time a system test workflow enters the deep system components within the client or middleware, there is no way to influence the target component state into programmatic intentional failure mode.

If there is no way to exercise a run time trajectory, then why bother? The reason is that exceptional conditions are exceptional. Resources can be exhausted, systems not available, and so forth. The rule of Fail Fast may not be enough if collaborating components are not exceptionally responsive.

Fault Injection

To see if a system is responding to exceptional conditions, one must wait for those conditions or create them.    Analogously to Fuzz Testing we can dynamically and randomly insert faults.  In Fuzz Testing, inputs are manipulated to a system under test.  In Fault Injection we have to manipulate inputs inside the real system, within the components themselves.  And as in Fuzz Testing, we can employ various strategies to do so, such as randomized faults, etc.   Of course, this system is not the deployed production system, it is the real system in a test environment, an internal full deployment.

Some approaches are: source modification, source macros, annotations, dependency injection (IOC), and Aspect Oriented Programming (AOP). Of course, there are many other techniques as found in open/closed projects, commercial products, and the research community.

Fault Injection using AOP

Since using the real system is required, a viable approach is to use the Instrumentation already available in the Java system. We could dynamically insert code that forces exceptions. AOP as implemented by the AspectJ language can already do this.

The major advantage of using AOP is that the source is not changed in any way. AspectJ is the state of the art in the Java ecosystem for using AOP.

Other approaches

Monitoring

BTrace (a Java oriented approach comparable to DTrace) is very interesting. However, since, like DTrace, it is meant to be safe, defect injection may not be doable. But, see this post on an unsafe mode for BTrace.

Source modification

One way of injecting failure is just to edit the source code and add strategic code that will cause the instigating failure.  An advanced form of this is Mutation Testing.   Code changes could be:  arguments with wrong values, nulls, deliberately thrown exceptions, etc.  For example, one can simply create a method that throws a runtime exception:


     *** DON'T DO THIS ***

    public static void REMOVE_XXX_FROM_XXX_SOURCE(){
       if(true){
          throw new NullPointerException(
             "\n\t****** DELIBERATE RUNTIME EXCEPTION*****\n");
       }
    }
    

Then insert invocations to this method at strategic points in the code, deploy to a test environment, and see if the expected results are obtained, such as logging output that can identify the cause, or that no side effects are recorded, such as incorrect data storage.

This is a low tech and error prone approach.  Most importantly, this is dangerous.  In the mad development rush to meet deadlines and also eat lunch, this code could make it into production!  Even with that horrific method name, it will wind up in production!  One would have to create deployment filters that stop the process if any “fault” inducing code is included.  Another reason why this is not a good approach is that it doesn’t scale very well.   Forcing exceptions is just one type of verification.  Another is setting values outside of expected ranges or states.  Thus, one would need many different kinds of source code insertions. 

Of course, Unit and Behavior based testing tools sets can supply these required verifications if included into the system as Built-In Self-Tests (BIST).

Built-In Self-Test

In the hardware realm, BIST as found in, for example, IEEE 1149.1 JTAG, has been very successful. On the software side, there is ongoing research on how to implement BIST-like capability. This would make Brad Cox’s concept of the “Software IC” even more powerful.

Macros

A somewhat viable approach to source code fault insertion is instead of inserting the faulting code,  insert “include” macros in the original source code that indicates what fault insertion should be done at a location.  A fault injection preprocessor can scan and insert the fault framework’s invocations to accomplish the requirement.  The source code build process can then simply enable or disable the use of the preprocessor.  This would however still require source code modification and an extra maintenance nightmare.  When the code changes the macros may also require change.

Annotations

Instead of macros, we could also use Annotations.  Annotations could explicitly state the runtime exceptional behavior “service level agreements” at the component level. These SLA could then be systematically manipulated to test if they really hold at the system level.

Dependency Injection

One can also inject exceptional behavior by dependency injection, using programmatic, declarative, or annotations, faulted components could be inserted (or created via Aspect Oriented Programming) into the target system.

AOP Demonstration

In listing one below, an ATM class uses a service to do some banking.

/**
 * Driver class for example. 
 * For a real system see:  https://bitbucket.org/aragost/javahg/
 * @author jbetancourt
 */
public class ATM {
	private BankService service = new BankService(1000);

	/** 
	 * Perform a banking action.
	 */
	public void transaction(){	
		{
			service.deposit(100L);
			service.withdraw(200L);
		}
		
		service.statement();		
	}
	
	/** Application entry point	 */
	public static void main(String[] args) {
		new ATM().transaction();
	}
}

Listing two is the BankService being used. Of course, a real service would be more complex.

/**
 * Example service.
 */
public class BankService {
	// Use Long to allow example's null for failure
	// injection.

	private BigDecimal balance;
	
	public BankService(long savings){
		this.balance = new BigDecimal(savings);
	}
	
	/** */
	public void deposit(Long amount){
		balance = balance.add(new BigDecimal(amount));
		System.out.println("Deposit:  " + amount);
	}
	
	/** */
	public void withdraw(Long amount){
		balance = balance.subtract(new BigDecimal(amount));
		System.out.println("Withdraw: " + amount);
	}
	
	/** */
	public void statement() {
		System.out.println("Balance:  " + balance);		
	}	
	
} // end BankService

A example Non-faulted execution result is:

Report: pointcut usage
  withdrawCut:   true ->  false
  depositCut:  false ->  false
       Deposit: 100
      Withdraw: 200
       Savings: 900

When we run the demo program we get:

Exception at the withdraw method.

Report: pointcut usage
withdrawCut:   true ->   true
depositCut:  false ->  false
Deposit: 100
Exception in thread "main" java.lang.NullPointerException
   at BankService.withdraw_aroundBody2(BankService.java:15
   at BankService.withdraw_aroundBody3$advice(BankService.java:81)
   at BankService.withdraw(BankService.java:1)
   at Main.main(Main.java:16)

Exception at the deposit method.

Report: 
pointcut usage
withdrawCut:   true ->  false
depositCut:  false ->   true
Exception in thread "main" java.lang.NullPointerException
   at BankService.deposit_aroundBody0(BankService.java:9)
   at BankService.deposit_aroundBody1$advice(BankService.java:81)
   at BankService.deposit(BankService.java:1)
   at Main.main(Main.java:15)

All pointcuts enabled.

Report: 
pointcut usagewithdrawCut:   true ->   true
depositCut:  false ->   true
Exception in thread "main" java.lang.NullPointerException
   at BankService.deposit_aroundBody0(BankService.java:9)
   at BankService.deposit_aroundBody1$advice(BankService.java:81)
   at BankService.deposit(BankService.java:1)
   at Main.main(Main.java:15)

Implementation

Now to test the exceptional behavior we want to fault the deposit and withdraw methods.
First we have a way of specifying what we want to fault by using a JSON configuration file:

{
	"__comments":[
		"File: properties.json"
	],
	"settings":{
		"random":true
	},
	
	"cuts":{
		"depositCut":false,
		"withdrawCut":true
	}	
}

The “cuts” settings indicate which AspectJ “pointcut” to turn on. The “random” setting indicates if we want the exceptions to be randomly inserted into the code base at the enabled pointcuts.

The Abstract failure injection aspect. Subclasses (aspects) will supply the actual pointcuts to specify where to ‘do’ the injection.

/**
 * FailureInjectionAspect.aj 
 * @author jbetancourt
 * 
 */

import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

/**
 * Abstract Aspect that determines if failure should occur.
 * @author jbetancourt
 * 
 */
public abstract aspect FailureInjectionAspect {
	private Map<String, Boolean> pointcutFlags = new HashMap<String, Boolean>();
	private volatile boolean initialized =false;
	
	/** 
	 * Initialize Failure injection aspect.
	 * @throws Exception 
	 * 
	 */
	protected void init() throws Exception {
		Config config = new Config();
		config.configure();
		pointcutFlags = config.getPointcutFlags();		
		initialized = true;
	}	

	/**
	 * Get boolean value for pointcut name.
	 * 
	 * @param name pointcut name.
	 * @return true if pointcut enabled.
	 * @throws IOException 
	 */
	protected boolean isPointcutEnabled(String name) {
		if(!initialized){
			try {
				init();
			} catch (Exception e) {
				throw new IllegalStateException(
						"Could not initialize object",e);
			}
		}
		
		boolean f = false;	
		Object val = pointcutFlags.get(name);
		if (null != val) {
			f = ((Boolean) val).booleanValue();
		}	

		return f;
	}
	
} // end FailureInjectionAspect.aj

Here is a aspect that uses a nulling type of injection.

/**
 * 
 * Example of an aspect for nulling an argument to a method.
 * @author jbetancourt
 *
 */
public aspect AmountFailureAspect extends FailureInjectionAspect {

	/** fault the deposit */
	private pointcut depositCut(Long amount) :
		execution(public void BankService.deposit(Long)) 
		&& if(AmountFailureAspect.aspectOf().isPointcutEnabled("depositCut"))
		&& args(amount) 
		&& !within(FailureInjectionAspect)
	;

	/** fault the withdrawal */
	private pointcut withdrawCut(Long amount) :
		execution(public void BankService.withdraw(Long)) 
		&& if(AmountFailureAspect.aspectOf().isPointcutEnabled("withdrawCut"))
		&& args(amount) 
		&& !within(FailureInjectionAspect)
	;

	/** Null the amount arg */
	void around(Long amount) : depositCut(amount)|| withdrawCut(amount) {
		amount = null;
		proceed(amount);
	}
}

Here is how to read the configuation JSON file. I use the JSON-Simple library.

import java.io.File;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
import java.io.Writer;
import java.util.HashMap;
import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;

import org.json.simple.JSONObject;
import org.json.simple.JSONValue;

/**
 * 
 * @author jbetancourt
 *
 */
public class Config {
	private static final Logger logger = 
          Logger.getLogger(Config.class.getName());
	private String configFile = "\\src\\properties.json";
	private Map<String, Boolean> pointcutFlags = new HashMap<String, Boolean>();
	private volatile boolean initialized = false;
	private String basePath;

	/**
	 * 
	 * @param configFile2 
	 * @throws Exception
	 */
	@SuppressWarnings("unchecked")
	public void configure() throws Exception {
		basePath = new File(".").getAbsolutePath();

		String path = basePath + configFile;

		Object obj = (JSONObject) JSONValue
				.parse(new FileReader(new File(path)));
		
		Map<String, Map<String, ?>> map = (Map<String, Map<String, ?>>) obj;
		pointcutFlags = (Map<String, Boolean>) map.get("cuts");
		Map<String, Object> settings = (Map<String, Object>) map
				.get("settings");
		
		Object r = settings.get("random");
		boolean randomize = (r != null && ((Boolean)r)) ;
		
		if(randomize){
			println(String.format(
			    "Pointcut usage\n%16s %6s    %6s","Name        ",
			    "Prior","Current"));
			
			for(Map.Entry<String, Boolean>entry : pointcutFlags.entrySet()){
				Boolean prior = entry.getValue();
				Boolean f = Math.random() > 0.65;
				entry.setValue(f);
				println(String.format(
					"%15s: %6s -> %6s", entry.getKey(),prior,f));
			}
			println("\n");		
		}		
		
		saveConfig();		
		initialized = true;		
		logger.log(Level.INFO,"Initialized: " + initialized);
	}
	
	/**
	 * Write the config settings to external JSON file.
	 * 
	 * Format is: { cutname : boolean , ... }
	 *   Example: {"withdrawCut":true,"depositCut":true}
	 * Will be used to set up behavior analysis service to 
	 * monitor response.
	 * 
	 * @throws IOException
	 */
	protected void saveConfig() throws IOException{
		String json = JSONValue.toJSONString(pointcutFlags);
		File file = new File(basePath + "\\runtimeProperties.json");
		FileWriter writer = new FileWriter(file);		
		writer.append(json);		
		writer.close();		
	}	

	/** getter */
	public Map<String, Boolean> getPointcutFlags() {
		return pointcutFlags;
	}

	/** setter */
	public void setPointcutFlags(Map<String, Boolean> cutFlags) {
		this.pointcutFlags = cutFlags;
	}

	/**
	 * Just a shortcut to System.out.println(String).
	 * @param s
	 */
	private void println(String s){
		System.out.println(s);
	}
}

Running at the command line

Using AspectJ is much easier in a supporting IDE like Eclipse. Below is the “mess”, unless you love the CLI, of compiling and running in a command shell. Could be made clean by creating aliases, scripts, etc.

cd src
src>javac -d ..\bin -cp ..\jars\json-simple-1.1.jar  *.java
src>java -cp ..\bin Main
Jun 9, 2011 3:18:24 PM Main main
INFO: Starting Main.....
   Deposit:  100
   Withdraw: 200
   Balance:  900

Now we change the flag from false to true in the runtimeInjection.json file:

src>type runtimeInjection.json | sed "s/false/true/" > temp
src>copy /Y temp runtimeInjection.json
src>del temp

Compile the aspects using the Aspectj “ajc” compiler.  Here we use 1.6 compliance level; destination of output to ..\bin folder; and give the classpath.

c:\Users\jbetancourt\Documents\projects\dev\AspectsForNullTesting\src&gt;\java\aspectj1.6\bin\ajc -1.6 -d ..\bin -cp "c:\java\aspectj1.6\lib\aspectjrt.
jar;c:\java\aspectj1.6\lib\aspectjtools.jar;c:\java\aspectj1.6\lib\aspectjweaver.jar;..\jars\json-simple-1.1.jar" -sourceroots .

Now we run the same Main program.  Since the pointcut flag is true, the advise is invoked and the list argument to the service(List) is set to null.

c:\Users\jbetancourt\Documents\projects\dev\AspectsForNullTesting&gt;java -cp "c:\java\aspectj1.6\lib\aspectjrt.jar;c:\java\aspectj1.6\lib\aspectjtools
.jar;c:\java\aspectj1.6\lib\aspectjweaver.jar;jars\json-simple-1.1.jar;bin;." Main
Jun 9, 2011 3:25:04 PM Main main
INFO: Starting Main.....
Pointcut usage
Name          Prior    Current
withdrawCut:   true -&gt;  false
depositCut:  false -&gt;  false
c:\Users\jbetancourt\Documents\projects\dev\AspectsForNullTesting&gt;java -cp "c:\java\aspectj1.6\lib\aspectjrt.jar;c:\java\aspectj1.6\lib\aspectjtools
.jar;c:\java\aspectj1.6\lib\aspectjweaver.jar;jars\json-simple-1.1.jar;bin;."   Main
Jun 9, 2011 3:25:10 PM Main main
INFO: Starting Main.....
Pointcut usage
Name          Prior    Current
withdrawCut:   true -&gt;   true
depositCut:  false -&gt;   true
Jun 9, 2011 3:25:10 PM Config exec
INFO: Initialized: true
Exception in thread "main" java.lang.NullPointerException
at BankService.deposit_aroundBody0(BankService.java:19)
at BankService.deposit_aroundBody1$advice(BankService.java:26)
at BankService.deposit(BankService.java:1)
at Main.main(Main.java:16)

c:\Users\jbetancourt\Documents\projects\dev\AspectsForNullTesting&gt;java -cp "c:\java\aspectj1.6\lib\aspectjrt.jar;c:\java\aspectj1.6\lib\aspectjtools
.jar;c:\java\aspectj1.6\lib\aspectjweaver.jar;jars\json-simple-1.1.jar;bin;."   Main
Jun 9, 2011 3:25:13 PM Main main
INFO: Starting Main.....
Pointcut usage
Name          Prior    Current
withdrawCut:   true -&gt;   true
depositCut:  false -&gt;  false
Jun 9, 2011 3:25:13 PM Config exec
INFO: Initialized: true
Deposit:  100
Exception in thread "main" java.lang.NullPointerException
at BankService.withdraw_aroundBody2(BankService.java:25)
at BankService.withdraw_aroundBody3$advice(BankService.java:26)
at BankService.withdraw(BankService.java:1)
at Main.main(Main.java:17)

Updates

  • Feb 1, 2012: Just learned about Byteman.

Further Reading



Nicolas Lens – Sumus Vicinae (Flamma Flamma)


Using AspectJ For Testing Legacy Code

October 19, 2010

Recently I brought up the topic of Aspect Oriented Programming (AOP) at work. I argued that it does have uses beyond mere tracing and psuedo-logging. In fact, it’s all over the place.

Just to get familiar with it again I looked at how it could be used on a test scenario I had. A class under test directly uses a Singleton collaborating class to invoke a service call, in other words non-dependency injection. This is similar to a class using “new” to create objects it depends on.

A requirement of unit testing is the isolation of the class from its collaborators (to a pragmatic degree). Since the Singleton class has a private constructor it can’t be subclassed or proxied (even with cglib via Mock frameworks).

I created a simplified version of the scenario to show how “easy” it is to use AOP. First the class under test class in listing one:

public class ClassUnderTest {
	/**   	 */
	public void service(){
		Collaborator.getInstance().speak();
	}

	/**  	 */
	public static void main(String[] args) {
		ClassUnderTest main = new ClassUnderTest();
		main.service();
	}

} // end ClassUnderTest

And, the collaborator singleton class is in listing two:

public class Collaborator {
	private static final Collaborator instance = new Collaborator();

	/**   */
	private Collaborator(){
	}

	/**  */
	public static Collaborator getInstance(){
		return instance;
	}

	/**  */
	public void speak(){
		System.out.println("Hello!");
	}

} // end class Collaborator

The result of a compile and run is:

src>javac -d ..\bin ClassUnderTest.java Collaborator.java
src>cd ..\bin
bin>dir
bin>java ClassUnderTest
Hello!

Now, the scenario goal is to change the speak() method to instead output “Goodbye!”. The aspect in listing three accomplishes this. It defines two pointcuts, cut() that specifies the class under test, and service() that identifies the target speak() method call in the collaborator object. The around() advice allows us to substitute our own replacement ‘method’. In the ‘around’ advice, using proceed() would let the original method execute. Note the terminology used here is not Aspectively correct.

public aspect TestAspect {

	pointcut cut() :
		execution(public void ClassUnderTest.service()) &&
		!within(TestAspect);

	pointcut service() : cflow(cut())
	    && call(public void Collaborator.speak());

	void around() : service() {
		System.out.println("Goodbye!");
		//proceed();
	}

} // end class TestAspect

Compiling:

.....\src>\java\aspectj1.6\bin\ajc -cp "c:\java\aspectj1.6\lib\aspectjrt.jar;c:\java\aspectj1.6\lib\aspectjtools.jar;c:\java\aspectj1.6\lib\aspectjweaver.jar" -sourceroots .
Compiler took 958ms
 

Running:

....\src>cd ..\bin

....\bin\java -cp "c:\java\aspectj1.6\lib\aspectjrt.jar;c:\java\aspectj1.6\lib\aspectjtools.jar;c:\java\aspectj1.6\lib\aspectjweaver.jar;." ClassUnderTest
Goodbye!

Success!

Of course, our aspect in real life would not “do” the actual required test actions, but instead delegate to a test class or stub to do so. This is especially important if the collaborator object has many methods that must be advised. At first I was trying to do this directly, swapping out the use of the Singleton Collaborator class using static crosscutting, to another dynamically generated stub or mock class. Though with AspectJ you can do some powerful stuff, the private constructor puts a kink in all that.

Left to the reader is actually making this work within an actual Unit Testing framework like JUnit.

Updates

  • 30 Oct 2010:  Another approach which in many cases may be better is using the JMockit framework.  It does work with real Singletons and other cases where AspectJ would be the only recourse.
  • 15 Dec 2010: If you can change the source code, a very simple test pattern is to extract the troublesome code lines into a method. Now that method can more easily be mocked.

Further Reading

This post is duplicated in new blog: Using AspectJ For Testing Legacy Code
JMockit, http://code.google.com/p/jmockit/

Advanced Mocking: Capturing State with Answer and Captors“, http://canoo.com/blog/?p=1592#captcha_input

Aspect Oriented Software Development

Why use an AOP language when other languages can now do Aspects?”, Josef Betancourt, http://goo.gl/r1YB

Next steps with aspects“, http://www.ibm.com/developerworks/java/library/j-aopwork16/

Testing legacy code“, Elliotte Rusty Harold, http://www.ibm.com/developerworks/java/library/j-legacytest.html

AspectJ, http://eclipse.org/aspectj/

Nicholas Lesiecki, “Test flexibly with AspectJ and mock objects“, 01 May 2002, http://www.ibm.com/developerworks/java/library/j-aspectj2/

Approaches to Mocking“, Simon Stewart, http://onjava.com/pub/a/onjava/2004/02/11/mocks.html?page=1

Use AOP to maintain legacy Java applications“, http://www.ibm.com/developerworks/java/library/j-aopsc2.html

Static crosscutting“, http://eclipse.org/aspectj/doc/released/progguide/semantics-declare.html

Qi4j, http://www.qi4j.org/ Fascinating project and concepts, IMHO.

Russ Miles, AspectJ Cookbook, O’Reilly Media, Inc., 2005

AspectJ In Action, Ramnivas Laddad, Manning, http://manning.com/laddad2/

Multi-threaded Testing with AOP Is Easy, and It Finds Bugs!“, http://www.springerlink.com/content/c8m3g6v2cp49xcg6/

Making AspectJ development easier with AJDT“, http://www.infoq.com/articles/aspectj-with-ajdt

Bodden, Eric; Havelund,Klaus. “Racer: Effective Race Detection Using AspectJ“, http://www.havelund.com/Publications/issta2008.pdf


Why use an AOP language when other languages can now do Aspects?

January 14, 2010

Interesting research,  JOT: Journal of Object Technology – How AspectJ is Used: An Analysis of Eleven AspectJ Programs: Sven Apel, on how an AOP language, specifically AspectJ, is used in a few sample projects.  Was it useful, required?  The jury is out.

Interestingly the author correctly mentions that some languages now have rudimentary support for handling of basic crosscutting concerns.   And, since the analyzed projects did not really need advanced AOP techniques,

“numbers indicate that languages that provide only basic crosscutting mechanisms are appropriate to implement a large extent of the analyzed programs.”  

Note that the study does not apply to container based AOP as used in frameworks such as JBossAOP and SpringAOP.  Several Dynamic Languages use a Metaobject Protocol.

I used AspectJ for some utility and diagnostic help.  The language is fine and the concepts are approachable.  It’s the configuration, tools, and environment hassles that put a damper on things.   That’s why frameworks and tool support like that found in Eclipse are critical.

Updates
9/11/2010:
Adding Logging around all of the Methods of a Class with Groovy“, Ted Naleid. http://naleid.com/blog/2010/09/11/adding-logging-around-all-of-the-methods-of-a-class-with-groovy/

Further Reading

JOT: Journal of Object Technology – How AspectJ is Used: An Analysis of Eleven AspectJ Programs, Sven Apel

McClean, John, “Painless AOP with Groovy“, http://www.infoq.com/articles/aop-with-groovy

Meta-object Protocol, http://en.wikipedia.org/wiki/Meta-object_protocol

Dynamic Programming Language, http://en.wikipedia.org/wiki/Dynamic_language

AspectJ, http://www.eclipse.org/aspectj/

AJDT, http://www.eclipse.org/ajdt/


Follow

Get every new post delivered to your Inbox.