An Introduction to Aspect-Oriented programming with JBoss AOP
·
Join the DZone community and get the full member experience.
Join For FreeJBoss Application Server ships with support for aspect-oriented programming, so you can use AOP in your applications deployed in JBoss AS. JBoss AS 5, which is currently available as a community release, has AOP built into its core. However, JBoss AOP is also available as a standalone framework for use in your other applications.
This article will take a simple example, and use JBoss AOP to add to its behaviour, while explaining some of the core functionality of JBoss AOP. We will look at encapsulating cross-cutting concerns into aspects, have a look at around advices vs the new lightweight advices in the upcoming JBoss AOP 2.0 release, and also look at using interface-introductions and mixins to add interfaces to your classes.
Table of Contents
- Our Core Application
Our Core Application
The application we will look at is is a simple banking application. It has a BankAccount class:
package bank;
public class BankAccount
{
int accountNumber;
int balance;
public BankAccount(int accountNumber)
{
System.out.println("*** Bank Account constructor");
this.accountNumber = accountNumber;
}
public int getAccountNumber()
{
return accountNumber;
}
public int getBalance()
{
return balance;
}
public void debit(int amount)
{
System.out.println("*** BankAccount.debit()");
balance -= amount;
}
public void credit(int amount)
{
System.out.println("*** BankAccount.credit()");
balance += amount;
}
}
In addition it has a main Bank class:
package bank;
import java.util.HashMap;
import java.util.Map;
public class Bank
{
static Map bankAccounts = new HashMap();
public static void transfer(BankAccount from, BankAccount to, int amount)
{
from.debit(amount);
to.credit(amount);
}
public static void main(String[] args)
{
System.out.println("*** Creating account 1");
BankAccount acc1 = new BankAccount(1);
acc1.credit(150);
bankAccounts.put(acc1.getAccountNumber(), acc1);
System.out.println("*** Creating account 2");
BankAccount acc2 = new BankAccount(2);
acc2.credit(230);
bankAccounts.put(acc2.getAccountNumber(), acc2);
System.out.println("*** Balance acount 1: " + acc1.getBalance());
System.out.println("*** Balance acount 2: " + acc2.getBalance());
//Transfer some money
System.out.println("*** Transfer 50 from account 1 to account 2");
transfer(acc1, acc2, 50);
System.out.println("*** Balance acount 1: " + acc1.getBalance());
System.out.println("*** Balance acount 2: " + acc2.getBalance());
}
}
As you can see, we create two bank accounts with their account numbers, set the initial balances, and then transfer 50 from account1 to account 2. Running this simple example we get the following expected output:
*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
*** Balance acount 1: 100
*** Balance acount 2: 280
The code for this example can be found in the listing1/ folder of .
Logging as a Cross-Cutting Concern
One of the main uses of AOP is to extract out cross-cutting concerns. Say we wanted to add some logging whenever an object is created, when its fields are set, and when its methods are called. The “obvious” way to do that in our example would be to go in and add logging statements to various points of our application. The problem with this approach is that there might be lots of places to edit, scattered around our system, so we would need to identify those places, make our changes, and recompile our application. To turn this behaviour off, we would need to remove our logging statements again and recompile our code again. So the “obvious” way both leads to bloat, and is difficult to turn on and off.
Using AOP we can encapsulate this cross-cutting code in an aspect. The aspect itself is just a normal class, which can hold state, extend other classes, everything you can do in a normal Java class.
package bank;
import org.jboss.aop.joinpoint.ConstructorInvocation;
import org.jboss.aop.joinpoint.FieldWriteInvocation;
import org.jboss.aop.joinpoint.MethodInvocation;
public class LoggingAspect
{
public Object log(ConstructorInvocation invocation) throws Throwable
{
try
{
System.out.println("C: Creating BankAccount using constructor " + invocation.getConstructor());
System.out.println("C: Account number: " + invocation.getArguments()[0]);
return invocation.invokeNext();
}
finally
{
System.out.println("C: Done");
}
}
public Object log(MethodInvocation invocation) throws Throwable
{
try
{
System.out.println("M: Calling method " + invocation.getMethod().getName());
System.out.println("M: Amount " + invocation.getArguments()[0]);
return invocation.invokeNext();
}
finally
{
System.out.println("M: Done");
}
}
public Object log(FieldWriteInvocation invocation) throws Throwable
{
BankAccount account = (BankAccount)invocation.getTargetObject();
System.out.println("F: setting field " + invocation.getField().getName() + " for BankAccount " + account.getAccountNumber());
System.out.println("F: Field old value " + account.getBalance());
System.out.println("F: New value will be " + invocation.getValue());
try
{
return invocation.invokeNext();
}
finally
{
System.out.println("F: Field new value " + account.getBalance());
System.out.println("F: Done");
}
}
}
The actual code implementing the cross-cutting concerns is encapsulated in methods called advice methods. For the type of advice methods that we are looking at now, around advice, the signature and format of the advice method is as shown here:
public Object (org.jboss.aop.joinpoint.Invocation invocation) throws Throwable
{
//Do something before
try
{
return invocation.invokeNext();
}
finally
{
//Do something after
}
}
The invocation parameter can be of type org.jboss.aop.joinpoint.Invocation, or one of its subclasses. Some of these are shown in the LoggingAspect, and which of the overloaded log methods gets called depends on what is being called once we apply our aspect. In the LoggingAspect we are able to handle calls to an object's constructor (the first log() method, starting on line 9), calls to an object's methods (the second log() method, starting on line 23) and calls to set a field (the third log() method, starting on line 37). These “events” are called joinpoints in AOP terminology. The invocation contains information about what field/method/constructor is being called. It also allows access to any arguments, and the object on which we are making the call. The around advice methods also contain a call to Invocation.invokeNext(), which propogates the call chain. If there are several advice methods applied to the target joinpoint, this call invokes the next advice in the chain. If this is the last advice in the chain, or as in our example, we are the only advice in the chain, the target joinpoint is called when we call Invocation.invokeNext().
To apply our aspects, we need some configuration to declare our aspects, and to select the joinpoints in our application where the advice methods should be applied. In JBoss AOP the easiest way to do this is with an xml configuration file, typically called jboss-aop.xml. First we declare our aspect:
<aop> <aspect class="bank.LoggingAspect"/>
A binding has a pointcut to choose which methods we should apply the advice to. In this case we have a constructor expression that selects the constructor of the bank.BankAccount class that has an int parameter. Note that all class names used in pointcut expressions must be fully qualified. The word new is a special identifier within the pointcut language to pick out a constructor. Next, the around part of the binding says that we should apply the log advice from the bank.LoggingAspect to the joinpoints matched by its pointcut. In other words, when we call BankAccount's constructor, the first LoggingAspect.log() method, which takes a ConstructorInvocation, is invoked.
<bind pointcut="execution(bank.BankAccount->new(int))"> <around aspect="bank.LoggingAspect" name="log"/> </bind>
The previous binding's pointcut only captures one joinpoint. The next one uses a wildcard in place of the method name, so we pick out all methods returning void that take an int parameter, regardless of their name. It looks a lot like the constructor expression in the previous binding, but also contains the return type of the methods we are interested in. This pointcut picks out BankAccount.debit() and BankAccount.credit(), and invokes the second LoggingAspect.log() method, which takes a MethodInvocation, when these methods are called.
<bind pointcut="execution(void bank.BankAccount->*(int))">
<around aspect="bank.LoggingAspect" name="log"/>
</bind>
Finally, we have a binding capturing writes to the balance field of the BankAccount class. In this case we are using a wildcard in place of the type's name, and the third LoggingAspect.log method, which takes a FieldWriteInvocation, will be invoked when the field's value is set:
<bind pointcut="set(* bank.BankAccount->balance)">
<around aspect="bank.LoggingAspect" name="log"/>
</bind>
In addition to wildcards, you can also capture whole inheritance hierarchies of classes, use typedefs for complex class expressions, all classes belonging to a package, and as we will see use annotations to capture a wide range of jonpoints.
To run this application with aop enabled, you need to pass in a few extra parameters into the jvm when starting it up, as we can see in the example's build.xml
<target name="run-load-time" depends="compile">
<java fork="yes" failOnError="true" className="bank.Bank">
<sysproperty key="jboss.aop.path" value="jboss-aop.xml"/>
<jvmarg value="-javaagent:../libraries/jboss-aop-jdk50-single.jar"/>
<classpath refid="classpath"/>
</java>
</target>
The jboss.aop.path parameter contains the path to the jboss-aop.xml that declares our aspects and binds advice methods to joinpoints. The -javaagent switch points to the JBoss AOP library, which in turn turns on load-time weaving. When a class is first loaded, JBoss AOP will intercept that event and modify the bytecode of the class to add the hooks required to trigger the aspects for our selected joinpoints. In addition to weaving at load-time, you can weave the classes using our aopc post-processor. An example of this is shown in the example's build.xml. Running the example with load-time weaving yields the following output, now with quite a lot of extra information coming from our logging aspect:
*** Creating account 1
C: Creating BankAccount using constructor public bank.BankAccount(int)
C: Account number: 1
*** Bank Account constructor
C: Done
M: Calling method credit
M: Amount 150
*** BankAccount.credit()
F: setting field balance for BankAccount 1
F: Field old value 0
F: New value will be 150
F: Field new value 150
F: Done
M: Done
*** Creating account 2
C: Creating BankAccount using constructor public bank.BankAccount(int)
C: Account number: 2
*** Bank Account constructor
C: Done
M: Calling method credit
M: Amount 230
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 0
F: New value will be 230
F: Field new value 230
F: Done
M: Done
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
M: Calling method debit
M: Amount 50
*** BankAccount.debit()
F: setting field balance for BankAccount 1
F: Field old value 150
F: New value will be 100
F: Field new value 100
F: Done
M: Done
M: Calling method credit
M: Amount 50
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 230
F: New value will be 280
F: Field new value 280
F: Done
M: Done
*** Balance acount 1: 100
*** Balance acount 2: 280
The code for this example can be found in the listing2/ folder of .
Externalising Security Checks
Logging is the common example used for introductions to AOP, so let's try doing something more interesting. Say we want to make sure that only users with the correct permissions can call a method. We could annotate our methods from BankAccount as follows:
package bank;
public class BankAccount
{
int accountNumber;
int balance;
@Roles(roles= {"admin"})
public BankAccount(int accountNumber)
{
System.out.println("*** Bank Account constructor");
this.accountNumber = accountNumber;
}
...
@Roles(roles= {"admin"})
public void debit(int amount)
{
System.out.println("*** BankAccount.debit()");
balance -= amount;
}
@Roles(roles= {"admin", "user"})
public void credit(int amount)
{
System.out.println("*** BankAccount.credit()");
balance += amount;
}
}
So only users with the role “admin” can create BankAccount instances and debit accounts, while users with the role “admin” or “user” can credit accounts. We have created a security.properties file to configure users and their roles:
admin=password;admin,user
guest=password;user
There is a user called 'admin' whose password is 'password' who has the roles 'admin' and 'user', and a user called 'guest' whose password is 'password' who only has the role 'user'.
We can then apply a SecurityAspect to the methods annotated with the @Roles annotation. Note that like everything else in the pointcut language the annotations need to be fully qualified. The “..” in place of the parameters in the pointcut expressions means we want this aspect to be applied to all constructors and methods annotated with @Roles regardless of the parameters it takes.
<aop>
<aspect class="bank.SecurityAspect"/>
<bind pointcut="execution(bank.BankAccount->@bank.Roles(..))">
<around aspect="bank.SecurityAspect" name="checkSecurity"/>
</bind>
<bind pointcut="execution(* bank.BankAccount->@bank.Roles(..))">
<around aspect="bank.SecurityAspect" name="checkSecurity"/>
</bind>
</aop>
The SecurityAspect then checks that the correct user is used:
package bank;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.net.URISyntaxException;
import java.net.URL;
import java.util.Arrays;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;
import org.jboss.aop.joinpoint.Invocation;
public class SecurityAspect
{
Map<String, String> usernamePassword = new HashMap<String, String>();
Map<String, List<String>> userRoles = new HashMap<String, List<String>>();
public SecurityAspect() throws FileNotFoundException, IOException, URISyntaxException
{
//Initialise the usernamePassword and userRoles maps
//with information from security.properties
}
public Object checkSecurity(Invocation invocation) throws Throwable
{
String username = LoginInfo.getUsername();
String password = usernamePassword.get(username);
if (password == null)
{
throw new SecurityException("Unknown user");
}
if (!password.equals(LoginInfo.getPassword()))
{
throw new SecurityException("Wrong password");
}
Roles rolesAnnotaton = (Roles)invocation.resolveAnnotation(Roles.class);
List<String> hasRoles = userRoles.get(username);
boolean hasRole = false;
if (hasRoles != null)
{
for (String role : rolesAnnotaton.roles())
{
if (hasRoles.contains(role))
{
hasRole = true;
break;
}
}
}
if (!hasRole)
{
throw new SecurityException("Wrong roles for user");
}
return invocation.invokeNext();
}
}
The roles needed to invoke the target joinpoint are got from the invocation using this call:
Roles rolesAnnotaton = (Roles)invocation.resolveAnnotation(Roles.class);
This does the same as calling java.lang.reflect.Method.getAnnotation() or java.lang.reflect.Constructor.getAnnotation() for the called method or constructor, but also allows for annotation overrides as part of the aop configuration, which are beyond the scope of this article. Although the type of invocation used in this example is Invocation, the specific type created by JBoss AOP will be ConstructorInvocation or MethodInvocation depending on what we are calling. The referenced LoginInfo class is just a wrapper around some static fields containing the username and password.
package bank;
public class LoginInfo
{
private static String username;
private static String password;
public static void setUsernameAndPassword(String username, String password)
{
LoginInfo.username = username;
LoginInfo.password = password;
}
public static String getUsername()
{
return username;
}
public static String getPassword()
{
return password;
}
}
Now let us modify the Bank.main() method to populate the LoginInfo fields:
public static void main(String[] args)
{
System.out.println("*** Log in as 'guest' - it does not have the correct roles to create an account");
LoginInfo.setUsernameAndPassword("guest", "password");
System.out.println("*** Attempting to create account 1");
try
{
BankAccount acc1 = new BankAccount(1);
acc1.credit(150);
bankAccounts.put(acc1.getAccountNumber(), acc1);
}
catch(SecurityException e)
{
System.out.println("!!! Expected SecurityException " + e.getMessage());
}
System.out.println("*** Log in as 'admin' - the roles are fine for the rest now");
LoginInfo.setUsernameAndPassword("admin", "password");
System.out.println("*** Creating account 1");
BankAccount acc1 = new BankAccount(1);
acc1.credit(150);
bankAccounts.put(acc1.getAccountNumber(), acc1);
System.out.println("*** Creating account 2");
BankAccount acc2 = new BankAccount(2);
acc2.credit(230);
bankAccounts.put(acc2.getAccountNumber(), acc2);
System.out.println("*** Balance acount 1: " + acc1.getBalance());
System.out.println("*** Balance acount 2: " + acc2.getBalance());
//Transfer some money
System.out.println("*** Transfer 50 from account 1 to account 2");
transfer(acc1, acc2, 50);
System.out.println("*** Balance acount 1: " + acc1.getBalance());
System.out.println("*** Balance acount 2: " + acc2.getBalance());
}
We first try to create a BankAccount with a user who does not have the required admin role, and then we do the rest, as before, with an user with the required roles. The output of running this application is:
*** Log in as 'guest' - it does not have the correct roles to create an account
*** Attempting to create account 1
!!! Expected SecurityException Wrong roles for user
*** Log in as 'admin' - the roles are fine for the rest now
*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
*** Balance acount 1: 100
*** Balance acount 2: 280
By using AOP to apply security, we have extracted the security checks into one place in our application, and used annotations to configure that. If we wanted to use a different mechanism of configuring the users we could leave the core application the same, write another aspect and easily change how we use security everywhere by modifying the jboss-aop.xml file.
The code for this example can be found in the listing3/ folder of .
Observer with Introductions and Mixins
Say we want to be able to be notified somehow when BankAccount.balance is changed. An option would be to implement the Observer pattern, but we don't want to include all the Observable plumbing code in our BankAccount class. First of all let's add an annotation to the field we want to monitor.
package bank;
public class BankAccount
{
int accountNumber;
@Observed
int balance;
...
}
Next we can write an implementation of Observable:
package bank;
import java.util.ArrayList;
import java.util.List;
public class ObservableMixin implements Observable
{
List<Observer> observers = new ArrayList<Observer>();
public void addObserver(Observer listener)
{
observers.add(listener);
}
public void removeObserver(Observer listener)
{
observers.remove(listener);
}
public void notifyObservers(Object event)
{
for (Observer observer : observers)
{
observer.update(event);
}
}
}
This is a mixin class, which implements the Observable interface. It contains all the plumbing code needed for the Observable part of the pattern. It can be introduced into other POJOs using the following xml
<aop>
<introduction expr="hasfield(* *->@bank.Observed)">
<mixin>
<interfaces>
bank.Observable
</interfaces>
<class>bank.ObservableMixin</class>
</mixin>
</introduction>
...
This does two things. It makes all classes that have a field annotated with @Observed implement the @Observable interface and implement those methods. Second, when anybody attempts to call the methods from the Observable interface, it delegates all the calls to an instance of the ObservableMixin.
Next we have an aspect to trap when the annotated fields change their values bound using the following xml.
...
<aspect class="bank.ObserverAspect"/>
<bind pointcut="set(* bank.BankAccount->@bank.Observed)">
<around aspect="bank.ObserverAspect" name="fieldChanged"/>
</bind>
</aop>
The aspect is an around advice that captures the values before and after modifying the field.
package bank;
import java.lang.reflect.Field;
import org.jboss.aop.joinpoint.FieldWriteInvocation;
public class ObserverAspect
{
public Object fieldChanged(FieldWriteInvocation invocation) throws Throwable
{
Observable tgt = (Observable)invocation.getTargetObject();
Field fld = invocation.getField();
String fieldName = fld.getName();
fld.setAccessible(true);
Object oldVal = invocation.getField().get(tgt);
Object result = invocation.invokeNext();
Object newVal = invocation.getField().get(tgt);
tgt.notifyObservers("Changed " + fieldName + " from " + oldVal + " to " + newVal);
return result;
}
}
Since the classes captured by the pointcut to select which classes should have the ObserverAspect applied are in the set of classes captured by the class expression to pick out classes that should have the Observable introduction and mixin, we can safely cast the target of the invocation to Observable. We then get the values before and after writing the field, and then use the Observable target object to notify the observers. As mentioned the call to Observable.notifyObservers() will end up inside BankAccount's ObservableMixin.
Finally, let us modify the Bank.main() method to register an Observer with a BankAccount instance
public static void main(String[] args)
{
System.out.println("*** Creating account 1");
BankAccount acc1 = new BankAccount(1);
acc1.credit(150);
bankAccounts.put(acc1.getAccountNumber(), acc1);
System.out.println("*** Creating account 2");
BankAccount acc2 = new BankAccount(2);
acc2.credit(230);
bankAccounts.put(acc2.getAccountNumber(), acc2);
System.out.println("Installing observer");
((Observable)acc2).addObserver(new Observer(){
public void update(Object evt)
{
System.out.println("!!! Observer: " + evt);
}
});
System.out.println("*** Balance acount 1: " + acc1.getBalance());
System.out.println("*** Balance acount 2: " + acc2.getBalance());
//Transfer some money
System.out.println("*** Transfer 50 from account 1 to account 2");
transfer(acc1, acc2, 50);
System.out.println("*** Balance acount 1: " + acc1.getBalance());
System.out.println("*** Balance acount 2: " + acc2.getBalance());
}
Although until woven the BankAccount class does not implement the Observable interface, the Java compiler does not perform any checks when casting to an interface (only to a superclass), so the cast from BankAccount to Observable will compile. (If the example is run without weaving you would get a ClassCastException since then BankAccount would not implement the Observable interface). When we run this example we can see the registered Observer gets triggered:
*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
Installing observer
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
!!! Observer: Changed balance from 230 to 280
*** Balance acount 1: 100
*** Balance acount 2: 280
The code for this example can be found in the listing5/ folder of .
Conclusion
We have taken a simple application, added extra behaviour to it using JBoss AOP, and explored a few of the features offered. Apart from adding a few annotations to help with our pointcut expressions (and there are even less intrusive, although more incovenient ways to achieve the similar effect), we have left the core application as is, and added extra cross-cutting behaviour such as logging and security by applying aspects, as well as using a combination of aspects, interface introductions and mixins to implement the Observer pattern.
JBoss AOP can be downloaded from http://www.jboss.org/jbossaop/ and comes with a tutorial to get you started.
Opinions expressed by DZone contributors are their own.
Comments