JBoss AOP - Aspect-Oriented Framework for Java

The section defines some basic terms that will be used throughout this guide.

JBoss AOP is a 100% pure Java framework. All your AOP constructs are defined as pure Java classes and bound to your application code via XML or by annotations. This Chapter walks through implementing aspects.

The Aspect Class is a plain Java class that can define zero or more advices, pointcuts, and/or mixins.

public class Aspect
 {
   public Object trace(Invocation invocation) throws Throwable {
      try {
         System.out.println("Entering anything");
         return invocation.invokeNext(); // proceed to next advice or actual call
      } finally {
         System.out.println("Leaving anything");
      }
   }
}

The example above is of an advice trace that traces calls to any type of joinpoint. Notice that Invocation objects are the runtime encapsulation of joinpoints. The method invocation.invokeNext() is used to drive the advice chain. It either calls the next advice in the chain, or does the actual method or constructor invocation.

For basic interception, any method that follows the form:

Object methodName(Invocation object) throws Throwable

can be an advice. The Invocation.invokeNext() method must be called by the advice code or no other advice will be called, and the actual method, field, or constructor invocation will not happen.

JBoss AOP provides five types of advice: before, around, after, finally and after-throwing. The advice sginature above is the default one for an around advice. Advices types, signature rules and overloading will be covered in Chapter 4, Advices.

Interceptors are a special type of aspect that contains only one advice. This advice has its signature defined by an interface, org.jboss.aop.advice.Interceptor:

public interface Interceptor
{
   public String getName();
   
   public Object invoke(Invocation invocation) throws Throwable;
}

The method invoke(Invocation) is the unique advice contained in an interceptor. The method getName() is used for identification in the JBoss AOP framework. So, this method must return a name that is unique in the whole system. It is only really used for aspects added to the InstanceAdvisor as shown in Section 7.2, “Per Instance AOP”.

JBoss AOP provides an abstraction for resolving annotations. In future versions of JBoss AOP, there will be a way to override annotation values on a per thread basis, or via XML overrides, or even provide VM and cluster wide defaults for annotation values. Also if you want to write a truly generic advice that takes the base Invocation type, you can still get the annotation value of the method, constructor, or field you're invoking on by calling this method:

Object resolveAnnotation(Class annotation);

That's just resolving for resolving member annotations. If your aspect needs to resolve class level annotations then this method should be called:

Object resolveClassAnnotation(Class annotation)

Mixins are a type of introduction in which you can do something like C++ multiple inheritance and force an existing Java class to implement a particular interface and the implementation of that particular interface is encapsulated into a particular class called a mixin.

Mixin classes have no restrictions other than they must implement the interfaces that you are introducing.

Dynamic CFlows allow you to define code that will be executed that must be resolved true to trigger positive on a cflow test on an advice binding. (See <cflow-stack> for more information). The test happens dynamically at runtime and when combined with a pointcut expression allows you to do runtime checks on whether a advice binding should run or not. To implement a dynamic CFlow you just have to implement the simple org.jboss.aop.pointcut.DynamicCFlow interface. You can then use it within cflow expressions. (See XML or Annotations)

public interface DynamicCFlow
{
   boolean shouldExecute(Invocation invocation);
}

There are two types of wildcards you can use within pointcut expressions

Type patterns are defined by an annotation or by fully qualified class name. Annotation expressions are not allowed to have wildcards within them, but class expressions are.

To reference all subtypes of a certain class (or implementors of an interface), the $instanceof{} expression can be used. Wildcards and annotations may also be used within $instanceof{} expressions.

         $instanceof{org.acme.SomeInterface}
         $instanceof{@org.acme.SomeAnnotation}
         $instanceof{org.acme.interfaces.*}
      

are all allowed.

For very complex type expressions, the Typedef construct can be used. To reference a Typedef within a class expression $typedef{id} is used.

public void org.acme.SomeClass->methodName(java.lang.String)

The attributes( public, static, private) of the method are optional. If the attribute is left out then any attribute is assumed. Attributes accept the ! modifier for negation.

public !static void org.acme.SomeClass->*(..)

$instanceof{} can be used in place of the class name.

void $instanceof{org.acme.SomeInterface}->methodName(java.lang.String)

To pick out all toString() methods of all classes within the org.acme package, we can use org.acme.. in place of the class name.

java.lang.String org.acme..->toString()

To only match methods from a given interface you can use the $implements{} or $implementing{} keywords in place of the method name. $implements{} only matches methods from the exact interface(s) given, while $implementing{} matches methods from the interface(s) given AND their super interfaces.

void $instanceof{org.acme.IfA}->$implements(org.acme.IfA)(..)

void $instanceof{org.acme.IfB}->$implementing(org.acme.IfA, org.acme.IfB)(..)

Annotations can be used in place of the class name. The below example matches any methodName() of a tagged @javax.ejb.Entity class.

void @javax.ejb.Entity->methodName(java.lang.String)

Annotations can be also be used in place of the method name. The below examples matches any method tagged as @javax.ejb.Tx.

* *->@javax.ejb.Tx(..)

In addition you can use typedefs, $instanceof{}, annotations and wildcards for method parameters and return types. The following matches all methods called loadEntity that return a class annotated with @javax.ejb.Entity, that takes a class (or a class whose superclass/interface is) annotated as @org.acme.Ann and any class that matches java.*.String (such as java.lang.String).

@javax.ejb.Entity *->loadEntity($instanceof{@org.acme.Ann}, java.*.String)

public void org.acme.SomeClass->methodName(java.lang.String) \
      throws org.acme.SomeException, java.lang.Exception

public org.acme.SomeClass->new(java.lang.String)

Constructor expressions are made up of the fully qualified classname and the new keyword The attributes( public, static, private) of the method are optional. If the attribute is left out then any attribute is assumed. Attributes accept the ! modifier for negation.

!public org.acme.SomeClass->new(..)

$instanceof{} can be used in the class name.

$instanceof{org.acme.SomeInterface}->new(..)

To pick out all no-args constructors of all classes within the org.acme package, we can use org.acme.. in place of the class name.

org.acme..->new()

Annotations can be used in place of the class name. The below example matches any constructor of a tagged @javax.ejb.Entity class.

@javax.ejb.Entity->new(..)

Annotations can be also be used in place of the new keyword. The below examples matches any constructor tagged as @javax.ejb.MethodPermission.

*->@javax.ejb.MethodPermission(..)

In addition, just as for methods you can use typedefs, $instanceof{}, annotations and wildcards for constructor parameters. The following matches all constructors that take a class annotated as @org.acme.Ann and any class that matches java.*.String (such as java.lang.String).

*->new(@org.acme.Ann, java.*.String)

You can also include an optional throws clause in the pointcut expression:

public void org.acme.SomeClass->new(java.lang.String) \
      throws org.acme.SomeException, java.lang.Exception

If any exceptions are present in the pointcut expression they must be present in the throws clause of the constructors to be matched.

public java.lang.String org.acme.SomeClass->fieldname

Constructor expressions are made up of the type, the fully qualified classname where the field resides and the field's name. The attributes( public, static, private) of the field are optional. If the attribute is left out then any attribute is assumed. Attributes accept the ! modifier for negation.

!public java.lang.String org.acme.SomeClass->*

$instanceof{} can be used in the class name. The below expression matches any field of any type or subtype of org.acme.SomeInterface

* $instanceof{org.acme.SomeInterface}->*

Annotations can be used in place of the class name. The below example matches any field where the type class is tagged with @javax.ejb.Entity.

* @javax.ejb.Entity->*

Annotations can be also be used in place of the field name. The below examples matches any field tagged as @org.jboss.Injected.

* *->@org.jboss.Injected

In addition, you can use typedefs, $instanceof{}, annotations and wildcards for field types. The following matches all fields where the type class has been tagged with @javax.ejb.Entity.

@javax.ejb.Entity *->*

To pick out all fields annotated with @org.foo.Transient within the org.acme package, we can use org.acme.. in place of the class name, and @org.foo.Transient in please of the field name

* org.acme..->@org.foo.Transient

Pointcuts use class, field, constructor, and method expressions to specify the actual joinpoint that should be intercepted/watched.

Pointcuts can be composed into boolean expressions.

Here's some examples.

call(void Foo->someMethod()) AND withincode(void Bar->caller())
execution(* *->@SomeAnnotation(..)) OR field(* *->@SomeAnnotation)

Pointcuts can be named in XML (Chapter 5, XML Bindings) or annotation (Chapter 6, Annotation Bindings) bindings. They can be referenced directly within a pointcut expression.

some.named.pointcut OR call(void Foo->someMethod())

Sometimes, when writing pointcuts, you want to specify a really complex type they may or may not have boolean logic associated with it. You can group these complex type definitions into a JBoss AOP Typedef either in XML or as an annotation (See later in this document). Typedef expressions can also be used within introduction expressions. Typedef expressions can be made up of has, hasfield, and class expressions. class takes a fully qualified class name, or an $instanceof{} expression.

class(org.pkg.*) OR has(* *->@Tx(..)) AND !class($instanceof{org.foo.Bar})

After getting acquainted with all pointcut constructs, let's see how this reflects on the API available to advices during their execution.

An around advice can follow this template:

public Object [advice name]([Invocation] invocation) throws Throwable
{
   try{
      // do something before joinpoint execution
      ...
      // execute the joinpoint and get its return value
      Object returnValue = invocation.invokeNext();
      // do something after joinpoint has executed successfully ...
      // return a value
      return returnValue;
   }
   catch(Exception e)
   {
      //handle any exceptions arising from calling the joinpoint
      throw e;
   }
   finally
   {
      //Take some action once the joinpoint has completed successfully or not
   }
}

In the template above, Invocation refers to one of the Invocation beans, and can be the class org.jboss.aop.joinpoint.Invocation or one of its subtypes.

Since an around advice wraps a joinpoint, it must proceed execution to the joinpoint itself during its execution. This can be done by calling the method invokeNext() on invocation. This method will proceed execution to the next around advice of that joinpoint. At the end of this chain this invokeNext() will proceed to the joinpoint itself. The value returned by the around advice will replace the joinpoint return value in the base system.

For example, in the case where there are two around advices bound to a joinpoint, the first around advice will trigger the second around advice by calling invokeNext(). The second advice will trigger the joinpoint execution by calling the same method. As a result of the invokeNext() execution, the second advice will receive the joinpoint return value. The value returned by this second advice will be received as a result by the first around advice. Finally, the value returned by this advice will replace the joinpoint return value in the base system execution. Normally though, around advices will simply return whatever value the joinpoint returned! This is shown in the preceding template example.

If an around advice wants to completely replace the joinpoint execution, it can skip the call to invokeNext(). This will also skip execution of any subsequent around advices in the chain. As a third alternative, the around advice can call the method invokeTarget() instead of invokeNext(). This method will invoke the target joinpoint directly, skipping any subsequent advices.

The presence of the Invocation parameter is optional. If an around advice does not have this parameter, it can replace the call to invokeNext() with a call to org.jboss.aop.joinpoint.CurrentInvocation.proceed().

The signature described before is the default around advice signature rule. In addition to it, the around advice signature can also be of this form (only in generated advisor mode):

public [return type] [advice name]([annotated parameter],[annotated parameter],...[annotated parameter]) throws Throwable

This signature is joinpoint dependent. The return type of the advice must be a type assignable to the the return type of the joinpoint to be intercepted (i.e. be the same type; a subclass, if the return type is class; or a subinterface or an implementing class, if the return type is an interface). In case the joinpoint being intercepted does not have a return type, this advice return type must be void.

An around advice can have zero or more annotated parameters. The annotated parameters will be covered in detail in Section 4.3, “Annotated Advice Parameters”.

Finally, JBoss AOP also features a special type of around advice: Interceptor. An interceptor class implements org.jboss.aop.Interceptor, and is described in Section 2.4, “Interceptors”.

These advices are more lightweight in the JBoss AOP framework, since they do not wrap a joinpoint, avoiding the creation of the Invocation objects per joinpoint execution.

Instead of Invocation objects, JBoss AOP provides JoinPointBean beans for these advices. As described in Section 3.10.1, “Joinpoint Beans”, these beans contain all information regarding a joinpoint, like an Invocation would do. However, since JoinPointBean objects are not used on around advice types, they do not provide proceeding methods, like invokeNext(). They also do not allow you to attach metadata for a particular invocation.

The rules for before, after, after-throwing and finally advices are quite similar. All of them can have zero or more annotated advice parameters in their signature, which will be described in the next subsection.

public void [advice name]([annotated parameter], [annotated parameter],...[annotated parameter])

public void [advice name]([annotated parameter], [annotated parameter],...[annotated parameter])

public [return type] [advice name]([annotated parameter], [annotated parameter],...[annotated parameter])

public void [advice name]([annotated parameter], [annotated parameter],...[annotated parameter])

public void [advice name]([annotated parameter], [annotated parameter],...[annotated parameter])

public [return type] [advice name]([annotated parameter], [annotated parameter],...[annotated parameter])

This section lists the annotated parameters that can be used on JBoss AOP advices (available only in generated advisor execution mode). Table 4.1, “Annotated Parameters Table” lists all annotations and their semantics.

Except for the @JoinPoint annotation, used to refer to joinpoint beans, all other annotations are used on parameters that contain joinpoint context values.

Notice that the types of annotated parameters are dependent on the joinpoint being intercepted by the advice.

JBoss AOP will accept any type that is assignable from the type referred by that parameter, as shown in the Type Assignable From column of the table below. For example, for a joinpoint whose target is of type POJO, the annotated parameter that receives the target must be of POJO type, one of POJO's superclasses, or one of the interfaces implemented by POJO.

Regarding the type of joinpoint bean parameters, the rules are the same for the default signature of around advices (without annotations). For example, an around advice that intercepts a method execution, can receive either a MethodInvocation, or an Invocation (the complete list of joinpoint beans and their relationship with joinpoint types was shown in Table 3.1, “ Joinpoint Types Table ”). As already explained, around advices use Invocation instances, while the other advices use JoinPointBean objects.

Notice also that only one annotated parameter can be mandatory: @Thrown. This will be further explained in Section 4.3.1, “@Thrown annotated parameter”.

Except for @Arg, all annotations are single-enforced, i.e., there must be at most only one advice parameter with that annotation per advice.

Due to the fact that most of these parameters represent context values, their availability depends on the joinpoint type. If an advice receives as a parameter a context value that is not available during a joinpoint execution, the parameter value will be null. The exception to this rule is @Return. If an advice has this parameter, it will not intercept joinpoints that don’t have a return value.

The only exception to this rule is @Args on field read joinpoints. Such an advice will be called with an empty arguments array, in that case.

public class Aspect
{
   public void throwing1(@Thrown RuntimeException thrownException)
   {
      ...
   }

   public void throwing2()
   {
      ...
   }
}


<aop>
   <aspect class="Aspect"/>
   <bind pointcut="...">
      <throwing aspect="Aspect" name="throwing1"/>
      <throwing aspect="Aspect" name="throwing2"/>
   </bind>
</aop>

public class Aspect
{
   public void finally1(@Thrown Throwable thrownException)
   {
      ...
   }

   public void finally2()
   {
      ...
   }

   public void finally3(@Return int returnedValue, @Thrown Throwable thrownException)
   {
      if (thrownException == null)

      {

         //We returned normally, the @Return parameter is valid

         int i = returnedValue;

      }

      else

      {

         //An exception happened while invoking the target joinpoint

         //The return value is invalid

      }

    }

   public void finally4(@Return int returnedValue)
   {
      ...
   }

}


<aop>
   <aspect class="Aspect"/>
   <bind pointcut="execution(public int *->*(..))">
      <finally aspect="Aspect" name="finally1"/>
      <finally aspect="Aspect" name="finally2"/>

      <finally aspect="Aspect" name="finally3"/>

      <finally aspect="Aspect" name="finally4"/>

   </bind>
</aop>

public class POJO
{
    void method(Collection arg0,  List arg1, int arg2, String arg3){}
}


<aop>
   <aspect class="MyAspect"/>
   <bind pointcut="execution(* POJO->method(..))">
      <before aspect="MyAspect" name="advice"/>
   </bind>
</aop>

public class MyAspect
{
   public void advice(@Arg Collection param0, @Arg List param1, @Arg int param2, @Arg String param3)
   {
      ...
   }
}

param0 <- arg0
param1 <- arg1
param2 <- arg2
param3 <- arg3
         

public class MyAspect
{
   public void advice (@Arg Collection param0, @Arg Collection param1, @Arg int param2, @Arg String param3)
   {
      ...
   }
}

public class MyAspect
{
   public void advice(@Arg Object param0)
   {
      ...
   }
}

param0 <- arg0
         

public class MyAspect
{
   public void advice(@Arg int param2, @Arg Collection param0, @Arg String param3, @Arg List param1)
   {
      ...
   }
}

public class MyAspect
{
   public void advice (@Arg Collection param1)
   {
      ...
   }
}

param1 <- arg0
         

public class MyAspect
{
   public void advice (@Arg(index=1) Collection param1)
   {
      ...
   }
}

param1 <- arg1
         

Method names can be overloaded for interception in different joinpoint scenarios. For instance, let's say you wanted to have a different trace advice for each invocation type. You can specify the same method name trace and just overload it with the concrete invocation type.

public class AroundAspect
{
   public Object trace(MethodInvocation invocation) throws Throwabl
   {
      try
      {
         System.out.println("Entering method: " + invocation.getMethod()");
         return invocation.invokeNext(); // proceed to next advice or actual call
      }
      finally
      {
         System.out.println("Leaving method: " + invocation.getMethod()");
      }
   }
   
   public Object trace(ConstructorInvocation invocation) throws Throwable
   {
      try
      {
         System.out.println("Entering constructor: " + invocation.getConstructor()");
         return invocation.invokeNext(); // proceed to next advice or actual call
      }
      finally
      {
         System.out.println("Leaving constructor: " + invocation.getConstructor()");
      }
   }
}

As you can see, the selection of the advice method is very dynamic. JBoss AOP will select the most appropriate advice method for each joinpoint interception. For the following setup:

class POJO
{
   public POJO(){}
   public someMethod(){}
}

<aop>
   <aspect class="AroundAspect"/>
   <bind pointcut="all(POJO)">
      <advice aspect="AroundAspect" name="trace"/>
   </bind>
</aop>

When calling POJO’s constructor:

pojo.someMethod();

JBoss AOP will call the trace() method taking a ConstructorInvocation, and when calling:

pojo.someMethod();

JBoss AOP will call the trace() method taking a MethodInvocation.

This examples shows that JBoss AOP will select the most appropriate advice method for each joinpoint interception. The capability of selecting overloaded advices is available for all types of advices. And its impact in the system performance is minimal since this selection is done once.

In this section, we will describe every rule JBoss AOP uses to select an advice method when this one is overloaded.

public class POJO
{
   String someMethod(String s){}
}

<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->someMethod(..))">
      <after aspect="OneAspect" name="after"/>
   </bind>
</aop>


public class OneAspect
{
   public void after(@JoinPoint MethodJoinPoint mjp){} //1
   public String after(@Target POJO pojo, @Return String ret, @Arg String arg0){} //2
}

public class POJO
{
   String someMethod(String s){}
}

<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->someMethod(..))">
      <after aspect="OneAspect" name="after"/>
   </bind>
</aop>


public class OneAspect
{
   public void after(@Target POJO pojo){} //1
   public String after(@Return String ret, @Arg String arg0){} //2
}

public class POJO
{
   String someMethod(String s){}
}

<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->someMethod(..))">
      <after aspect="OneAspect" name="after"/>
   </bind>
</aop>


public class OneAspect
{
   public void after(@JoinPoint MethodJoinPoint mjp, @Target POJO pojo){} //1
   public String after(@JoinPoint MethodJoinPoint mjp, @Return String ret){} //2
}

public class POJO
{
   String someMethod(String s, int i){}
}

<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->someMethod(..))">
      <before aspect="OneAspect" name="before"/>
   </bind>
</aop>


public class OneAspect
{
   public void before(@Arg String s, @Arg int i){} //1
   public String before(@Arg String s){} //2
}

public interface POJOInterface{}

public class POJOSuperClass extends java.lang.Object{}

public class POJO extends POJOSuperClass implements POJOInterface
{
   void method(){}
}

<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->method(..))">
      <before aspect="OneAspect" name="before"/>
   </bind>
</aop>

public class OneAspect
{
   public void before(@Target POJO target){} //1
   public void before(@Target POJOInterface target){} //2
   public void before(@Target POJOSuperClass target){} //3
   public void before(@Target Object target){} //4
}

public class POJO
{
   public void method(POJO argument0, String argument1, int argument2)
}


<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->method(..))">
      <before aspect="OneAspect" name="before"/>
   </bind>
</aop>


public class OneAspect
{
   public void before(@Arg POJO p, @Arg String s, @Arg int i){} //1
   public void before(@Arg POJOSuperClass p, @Arg String s, @Arg int i){} //2
   public void before(@Arg POJO p, @Arg Object s, @Arg int i){} //3
   public void before(@Arg Object p, @Arg Object s, @Arg int i){} //4
}

public class POJO
{
   public Collection method(int arg0, boolean arg1, short arg2) {…}
}


<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->method(..))">
      <advice aspect="OneAspect" name="around"/>
   </bind>
</aop>


public class OneAspect
{
   public Collection around(@JoinPoint Invocation inv, @Arg int param0) throws Throwable
   {...} //1

   public List around(@JoinPoint Invocation inv, @Arg boolean param1) throws Throwable
   {...} //2

}

<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->method(..))">
      <after aspect="OneAspect" name="around"/>
   </bind>
</aop>


public class OneAspect
{
   public Collection after(@Arg int param0) {...} //1
   public List after(@Arg boolean param1) { ... } //2
   public void after(@Arg short param2) { ... }   //3
}

public class POJO
{
   public void method(int arg0, long arg1) {…}
}


<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="execution(* POJO->method(..))">
      <before aspect="OneAspect" name="before"/>
   </bind>
</aop>


public class OneAspect
{
   public void advice(@Arg int arg0) {}
   public void advice(@Arg long arg1) {}
}

class POJO
{
   public int field;
   public POJO(){}
   public someMethod(){}
}


public class OneAspect
{
   public Object trace(MethodInvocation invocation) throws Throwable {...} //1
   public Object trace(ConstructorInvocation invocation) throws Throwable {...} //2
   public Object trace(Invocation invocation) throws Throwable {...} //3
   public Object trace() throws Throwable {...} //4
}


<aop>
   <aspect class="OneAspect"/>
   <bind pointcut="all(POJO)">
      <advice aspect="OneAspect" name="trace"/>
   </bind>
</aop>

public Object [advice name]([Invocation] invocation) throws Throwable

public Object [advice name]([Invocation] invocation) throws Throwable

public Object [advice name]() throws Throable

While writing advices and bindings, it is possible to make some mistakes, like, for example, mistyping the advice name, or writing an advice with an invalid signature.

Whenever there is a mistake in the advice name or signature, JBoss AOP will throw an exception with a message stating the cause of the error. The exception thrown is a runtime exception and should not be treated. Instead, it indicates a mistake that must be fixed.

There are two types of exceptions JBoss AOP can throw on those cases:

In the last sections you saw how to code aspects and how pointcut expressions are formed. This chapter puts it all together. There are two forms of bindings for advices, mixins, and introductions. One is XML which will be the focus of this chapter. The Annotated Bindings chapter discusses how you can replace XML with annotations.

JBoss AOP resolves pointcut and advice bindings at runtime. So, bindings are a deployment time thing. How does JBoss AOP find the XML files it needs at runtime? There are a couple of ways.

<aop xmlns="urn:jboss:aop-beans:1.0">
<!--  The exact contents will be explained below -->
</aop>
            
            

The xml schema can be found in the distribution's etc/literal> folder.

The <aspect> tag specifies to the AOP container to declare an aspect class. It is also used for configuring aspects as they are created and defining the scope of the aspects instance.

<aspect class="org.jboss.MyAspect"/>

<aspect class="org.jboss.MyAspect" scope="PER_VM"/>

<aspect class="org.jboss.SomeAspect">
     <attribute name="SomeIntValue">55</attribute>
     <advisor-attribute name="MyAdvisor"/>
     <instance-advisor-attribute name="MyInstanceAdvisor"/>
     <joinpoint-attribute name="MyJoinpoint"/>
</aspect>

<aspect class="org.jboss.SomeAspect">
        <attribute name="SomeIntValue">55</attribute>
        <advisor-attribute name="MyAdvisor"/>
        <instance-advisor-attribute name="MyInstanceAdvisor"/>
        <joinpoint-attribute name="MyJoinpoint"/>
</aspect>

public class SomeAspect {
   public SomeAspect() {}

   public void setSomeIntValue(int val) {...}
   public void setMyAdvisor(org.jboss.aop.Advisor advisor) {...}
   public void setMyInstanceAdvisor(org.jboss.aop.InstanceAdvisor advisor) {...}
   public void setMyJoinpoint(org.jboss.aop.joinpoint.Joinpoint joinpoin) {...}
}

<aspect name="MyAspect" factory="org.jboss.AspectConfigFactory" scope="PER_CLASS">
     <some-arbitrary-xml>value</some-arbitrary-xml>
</aspect>

<interceptor class="org.jboss.MyInterceptor" scope="PER_VM"/>
<interceptor class="org.jboss.SomeInterceptor">
     <attribute name="SomeIntValue">55</attribute>
     <advisor-attribute name="MyAdvisor"/>
     <instance-advisor-attribute name="MyInstanceAdvisor"/>
     <joinpoint-attribute name="MyJoinpoint"/>
</interceptor>
<interceptor name="MyAspect" factory="org.jboss.InterceptorConfigFactory" scope="PER_CLASS">
  <some-arbitrary-xml>value</some-arbitrary-xml>
</interceptor>

Interceptors are defined in XML the same exact way as aspects are. No difference except the tag. If there is no name attribute defined, the name of the interceptor is the same as the class or factory attribute value.

<bind pointcut="execution(void Foo->bar())">
      <interceptor-ref name="org.jboss.MyInterceptor/>
      <before name="beforeAdvice" aspect="org.jboss.MyAspect"/>
      <around name="aroundAdvice" aspect="org.jboss.MyAspect"/>
      <after name="afterAdvice" aspect="org.jboss.MyAspect"/>
      <throwing name="throwingAdvice" aspect="org.jboss.MyAspect"/>
      <finally name="finallyAdvice" aspect="org.jboss.MyAspect"/>
      <advice name="trace" aspect="org.jboss.MyAspect"/>
</bind>

In the above example, the MyInterceptor interceptor and several advice methods of the MyAspect class will be executed when the Foo.bar method is invoked.

Stacks allow you to define a predefined set of advices/interceptors that you want to reference from within a bind element.

<stack name="stuff">
      <interceptor class="SimpleInterceptor1" scope="PER_VM"/>
      <advice name="trace" aspect="org.jboss.TracingAspect"/>
      <interceptor class="SimpleInterceptor3">
           <attribute name="size">55</attribute>
      </interceptor>
</stack>

After defining the stack you can then reference it from within a bind element.

<bind pointcut="execution(* POJO->*(..))">
       <stack-ref name="stuff"/>
</bind>

The pointcut tag allows you to define a pointcut expression, name it and reference it within any binding you want. It is also useful to publish pointcuts into your applications to that others have a clear set of named integration points.

<pointcut name="publicMethods" expr="execution(public * *->*(..))"/>
<pointcut name="staticMethods" expr="execution(static * *->*(..))"/>

The above define two different pointcuts. One that matches all public methods, the other that matches the execution of all static methods. These two pointcuts can then be referenced within a bind element.

<bind pointcut="publicMethods AND staticMethods">
      <interceptor-ref name="tracing"/>
</bind>
         

Annotation introductions allow you to embed an annotation within a the class file of the class. You can introduce an annotation to a class, method, field, or constructor.

<annotation-introduction expr="constructor(POJO->new())">
      @org.jboss.complex (ch='a', string="hello world", flt=5.5, dbl=6.6, shrt=5, lng=6, \
      integer=7, bool=true, annotation=@single("hello"), array={"hello", "world"}, \
      clazz=java.lang.String)
</annotation-introduction>

The expr attribute takes method(), constructor(), class(), or field(). Within those you must define a valid expression for that construct. The following rules must be followed for the annotation declaration:

Control flow is a runtime construct. It allows you to specify pointcut parameters revolving around the call stack of a Java program. You can do stuff like, if method A calls method B calls Method C calls Method D from Constructor A, trigger this advice. In defining a control flow, you must first paint a picture of what the Java call stack should look like. This is the responsibility of the cflow-stack.

<cflow-stack name="recursive2">
      <called expr="void POJO->recursive(int)"/>
      <called expr="void POJO->recursive(int)"/>
      <not-called expr="void POJO->recursive(int)"/>
</cflow-stack>

A cflow-stack has a name and a bunch of called and not-called elements that define individual constructor or method calls with a Java call stack. The expr attribute must be a method or constructor expression. called states that the expr must be in the call stack. not-called states that there should not be any more of the expression within the stack. In the above example, the cflow-stack will be triggered if there are two and only two calls to the recursive method within the stack. Once the cflow-stack has been defined, it can then be referenced within a bind element through the cflow attribute. Boolean expressions are allowed here as well.

<bind pointcut="execution(void POJO->recursive(int))" cflow="recursive2 AND !cflow2">
      <interceptor class="SimpleInterceptor"/>
</bind>

<typedef name="jmx" expr="class(@org.jboss.jmx.@MBean) OR \
                          has(* *->org.jboss.jmx.@ManagedOperation) OR \
                          has(* *->org.jboss.jmx.@ManagedAttribute)"/>

typedefs allow you to define complex type expressions and then use then pointcut expressions. In the above example, we're defining a class that is tagged as @Mbean, or has a method tagged as @ManagedOperaion or @ManagedAttribute. The above typedef could then be used in a pointcut, introduction, or bind element

<pointcut name="stuff" expr="execution(* $typedef{jmx}->*(..))"/>
<introduction expr="class($typedef{jmx})">

dynamic-cflow allows you to define code that will be executed that must be resolved true to trigger positive on a cflow test on an advice binding. The test happens dynamically at runtime and when combined with a pointcut expression allows you to do runtime checks on whether a advice binding should run or not. Create a dynamic cflow class, by implementing the following interface.

package org.jboss.aop.pointcut;

import org.jboss.aop.joinpoint.Invocation;

/**
 * Dynamic cflow allows you to programmatically check to see if
 * you want to execute a given advice binding.
 *
 * @author <a>Bill Burke</a>
 * @version $Revision: 79662 $
 *
 **/
public interface DynamicCFlow
{
   boolean shouldExecute(Invocation invocation);
}
         

You must declare it with XML so that it can be used in bind expressions.

<dynamic-cflow name="simple" class="org.jboss.SimpleDynamicCFlow"/>

You can then use it within a bind

<bind expr="execution(void Foo->bar())" cflow="simple">

The prepare tag allows you to define a pointcut expression. Any joinpoint that matches the expression will be aspectized and bytecode instrumented. This allows you to hotdeploy and bind aspects at runtime as well as to work with the per instance API that every aspectized class has. To prepare something, just define a pointcut expression that matches the joinpoint you want to instrument.

<prepare expr="execution(void Foo-bar())"/>

You can attach untyped metadata that is stored in org.jboss.aop.metadata.SimpleMetaData structures within the org.jboss.aop.Advisor class that manages each aspectized class. The XML mapping has a section for each type of metadata. Class, method, constructor, field, and defaults for the whole shabang. Here's an example:

<metadata tag="testdata" class="org.jboss.test.POJO">
      <default>
         <some-data>default value</some-data>
      </default>
      <class>
         <data>class level</data>
      </class>
      <constructor expr="POJOConstructorTest()">
         <some-data>empty</some-data>
      </constructor>
      <method expr="void another(int, int)">
         <other-data>half</other-data>
      </method>
      <field name="somefield">
         <other-data>full</other-data>
      </field>
</metadata>

Any element can be defined under the class, default, method, field, and constructor tags. The name of these elements are used as attribute names in SimpleMetaData structures. The tag attribute is the name used to reference the metadata within the Advisor, or Invocation lookup mechanisms.

<metadata-loader tag="security" class="org.jboss.aspects.security.SecurityClassMetaDataLoader"/>

If you need more complex XML mappings for untyped metadata, you can write your own metadata binding. The tag attribute is used to trigger the loader. The loader class must implement the org.jboss.aop.metadata.ClassMetaDataLoader interface.

public interface ClassMetaDataLoader
{
   public ClassMetaDataBinding importMetaData(Element element, String name,
                                              String tag, String classExpr) throws Exception;

   public void bind(ClassAdvisor advisor, ClassMetaDataBinding data,
                    CtMethod[] methods, CtField[] fields, CtConstructor[] constructors) \
                    throws Exception;

   public void bind(ClassAdvisor advisor, ClassMetaDataBinding data,
                    Method[] methods, Field[] fields, Constructor[] constructors) \ 
                    throws Exception;
}

Any arbitrary XML can be in the metadata element. The ClassMetaDataBinding.importMetaData method is responsible for parsing the element and building ClassMetaDataBinding structurs which are used in the precompiler and runtime bind steps. Look at the SecurityClassMetaDataLoader code shown above for a real concrete example.

Precedence allows you to impose an overall relative sorting order of your interceptors and advices.

         <precedence>
            <interceptor-ref name="org.acme.Interceptor"/>
            <advice aspect="org.acme.Aspect" name="advice1"/>
            <advice aspect="org.acme.Aspect" name="advice2"/>
         </precedence>         
      

This says that when a joinpoint has both org.acme.Interceptor and org.acme.Aspect.advice() bound to it, org.acme.Interceptor must always be invoked before org.acme.Aspect.advice1() which must in turn be invoked before org.acme.Aspect.advice2(). The ordering of interceptors/advices that do not appear in a precedence is defined by their ordering for the individual bindings or intercerceptor stacks.

You can declare checks to be enforced at instrumentation time. They take a pointcut and a message. If the pointcut is matched, the message is printed out.

   <declare-warning expr="class($instanceof{VehicleDAO}) \
            AND !has(public void *->save())">
         All VehicleDAO subclasses must override the save() method.
   </declare-warning> 

      <declare-error expr="call(* org.acme.businesslayer.*->*(..)) \
            AND within(org.acme.datalayer.*)">
      Data layer classes should not call up to the business layer
   </declare-error> 

To mark a class as an aspect you annotate it with the @Aspect annotation. Remember that a class to be used as an aspect does not need to inherit or implement anything special, but it must have an empty constuctor and contain one or more methods (advices) of the format:

public Object <any-method-name>(org.jboss.aop.joinpoint.Invocation)

The declaration of org.jboss.aop.Aspect is:

   package org.jboss.aop;

   import org.jboss.aop.advice.Scope;
   import java.lang.annotation.ElementType;
   import java.lang.annotation.Retention;
   import java.lang.annotation.RetentionPolicy;
   import java.lang.annotation.Target;


   @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
           public @interface Aspect
   {
      Scope scope() default Scope.PER_VM;
   }

         

and Scope is:

   package org.jboss.aop.advice;

   public enum Scope
   {
      PER_VM, PER_CLASS, PER_INSTANCE, PER_JOINPOINT
   }
         

See Section 5.4.2, “Scope” for a description of the various scopes.

We use the @Aspect annotation as follows:

   package com.mypackage;

   import org.jboss.aop.Aspect;
   import org.jboss.aop.advice.Scope;
   import org.jboss.aop.joinpoint.Invocation;

   @Aspect (scope = Scope.PER_VM)
   public class MyAspect
   {
      public Object myAdvice(Invocation invocation)
   }

         

The name of the class (in this case com.mypackage.MyAspect) gets used as the internal name of the aspect. The equivalent using XML configuration would be:

            <aop>
            <aspect class="com.mypackage.MyAspect" scope="PER_VM"/>
            </aop>
         

To mark a class as an interceptor or an aspect factory you annotate it with the @InterceptorDef annotation. The class must either implement the org.jboss.aop.advice.Interceptor interface or the org.jboss.aop.advice.AspectFactory interface.

The declaration of org.jboss.aop.InterceptorDef is:

   package org.jboss.aop;

   @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
           public @interface Aspect
   {
      Scope scope() default Scope.PER_VM;
   }

         

The same Scope enum is used as for Aspect. The following examples use the @Bind annotation, which will be described in more detail below.

   package com.mypackage;

   import org.jboss.aop.Bind;
   import org.jboss.aop.InterceptorDef;
   import org.jboss.aop.advice.Interceptor;

   @InterceptorDef (scope = Scope.PER_VM)
   @Bind (pointcut="execution("* com.blah.Test->test(..)")
   public class MyInterceptor implements Interceptor
   {
      public Object invoke(Invocation invocation)throws Throwable
      {
         return invocation.invokeNext();
      }
   }

            

               <aop>
               <interceptor class="com.mypackage.MyInterceptor" scope="PER_VM"/>
               </aop>
            

   package com.mypackage;

   import org.jboss.aop.advice.AspectFactory;

   @InterceptorDef (scope=org.jboss.aop.advice.Scope.PER_VM)
   @Bind (pointcut="execution("* com.blah.Test->test2(..)")
   public class MyInterceptorFactory implements AspectFactory
   {
      //Implemented methods left out for brevity
   }
            

To define a named pointcut you annotate a field within an @Aspect or @InterceptorDef annotated class with @PointcutDef. @PointcutDef only applies to fields and is not recognised outside @Aspect or @InterceptorDef annotated classes.

The declaration of org.jboss.aop.PointcutDef is:

package org.jboss.aop;

@Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
public @interface PointcutDef
{
   String value();
}

@PointcutDef takes only one value, a valid pointcut expression. The name of the pointcut used internally and when yo want to reference it is:

<name of @Aspect/@InterceptorDef annotated class>.<name of @PointcutDef annotated field>

An example of an aspect class containing a named pointcut which it references from a bindng's pointcut expression:

   package com.mypackage;

   import org.jboss.aop.PointcutDef;
   import org.jboss.aop.pointcut.Pointcut;

   @Aspect (scope = Scope.PER_VM)
   public class MyAspect
   {
      @PointcutDef ("(execution(* org.blah.Foo->someMethod()) OR \
	      execution(* org.blah.Foo->otherMethod()))")
      public static Pointcut fooMethods;

      public Object myAdvice(Invocation invocation)
      {
         return invocation.invokeNext();
      }
   }
         

It is worth noting that named pointcuts can be referenced in pointcut expressions outside the class they are declared in (if the annotated fields are declared public of course!).

Using XML configuration this would be:

            <aop>
            <aspect class="com.mypackage.MyAspect" scope="PER_VM"/>
            <pointcut
            name="com.mypackage.MyAspect.fooMethods"
            expr="(execution(* org.blah.Foo->someMethod()) OR \
                  execution(* org.blah.Foo->otherMethod()))"
      />
            </aop>
         

To create a binding to an advice method from an aspect class, you annotate the advice method with @Bind. To create a binding to an Interceptor or AspectFactory, you annotate the class itself with @Bind since Interceptors only contain one advice (the invoke() method). The @Bind annotation will only be recognised in the situations just mentioned.

The declaration of org.jboss.aop.Bind is:

package org.jboss.aop;

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
public @interface Bind
{
  AdviceType type() default AdviceType.AROUND;
  String pointcut();
  String cflow() default "";
}
         

The @Bind annotation takes three parameters:

In the case of a binding to an advice in an aspect class, the internal name of the binding becomes:

<name of the aspect class>.<the name of the advice method>

In the case of a binding to an Interceptor or AspectFactory implementation, the internal name of the binding becomes:

<name of the Interceptor/AspectFactory implementation class>

An example of a binding using an advice method in an aspect class:

   package com.mypackage;

   import org.jboss.aop.Bind;

   @Aspect (scope = Scope.PER_VM)
   public class MyAspect
   {
      @PointcutDef ("(execution(* org.blah.Foo->someMethod()) \
            OR execution(* org.blah.Foo->otherMethod()))")
      public static Pointcut fooMethods;

      @Bind (pointcut="com.mypackage.MyAspect.fooMethods")
      public Object myAdvice(Invocation invocation)
      {
         return invocation.invokeNext();
      }

      @Bind (pointcut="execution("* org.blah.Bar->someMethod())")
      public Object myAdvice(Invocation invocation)
      {
         return invocation.invokeNext();
      }

   }
         

         <aop>
         <aspect class="com.mypackage.MyAspect" scope="PER_VM"/>
         <pointcut
         name="com.mypackage.MyAspect.fooMethods"
         expr="(execution("* org.blah.Foo->someMethod()) OR \
               execution("* org.blah.Foo->otherMethod()))"
      />
         <bind pointcut="com.mypackage.MyAspect.fooMethods">
         <advice name="myAdvice" aspect="com.mypackage.MyAspect">
         </bind>
         <bind pointcut="execution("* org.blah.Bar->someMethod())">
         <advice name="otherAdvice" aspect="com.mypackage.MyAspect">
         </bind>
         </aop>
      

Revisiting the examples above in the @InterceptorDef section, now that we know what @Bind means, the equivalent using XML configuration would be:

            <aop>
            <interceptor class="com.mypackage.MyInterceptor" scope="PER_VM"/>
            <interceptor factory="com.mypackage.MyInterceptorFactory" scope="PER_VM"/>

            <bind pointcut="execution("* com.blah.Test->test2(..)">
            <interceptor-ref name="com.mypackage.MyInterceptor"/>
            </bind>
            <bind pointcut="execution("* com.blah.Test->test2(..)">
            <interceptor-ref name="com.mypackage.MyInterceptorFactory"/>
            </bind>
            </aop>
         

Interface introductions can be done using the @Introduction annotation. Only fields within a class annotated with @Aspect or @InterceptorDef can be annotated with @Introduction.

The declaration of org.jboss.aop.Introduction:

   package org.jboss.aop;

   @Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
   public @interface Introduction
   {
      Class target() default java.lang.Class.class;
      String typeExpression() default "";
      Class[] interfaces();
   }
         

The parameters of @Introduction are:

target or typeExpression has to be specified, but not both.

This is how to use this annotation:

   package com.mypackage;

   import org.jboss.aop.Introduction;

   @Aspect (scope = Scope.PER_VM)
   public class IntroAspect
   {
      @Introduction (target=com.blah.SomeClass.class, \
            interfaces={java.io.Serializable.class})
      public static Object pojoNoInterfacesIntro;
   }
         

This means make com.blah.SomeClass.class implement the java.io.Serializable interface. The equivalent configured via XML would be:

            <introduction class="com.blah.SomeClass.class">
            <interfaces>
         java.io.Serializable
            </interfaces>
            </introduction>
         

Sometimes when we want to introduce/force a new class to implement an interface, that interface introduces new methods to a class. The class needs to implement these methods to be valid. In these cases a mixin class is used. The mixin class must implement the methods specified by the interface(s) and the main class can then implement these methods and delegate to the mixin class.

Mixins are created using the @Mixin annotation. Only methods within a class annotated with @Aspect or @InterceptorDef can be annotated with @Mixin. The annotated method has

The declaration of org.jboss.aop.Mixin:

   package org.jboss.aop;

   @Target({ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME)
   public @interface Mixin
   {
      Class target() default java.lang.Class.class;
      String typeExpression() default "";
      Class[] interfaces();
      boolean isTransient() default true;
   }
         

The parameters of @Mixin are:

target or typeExpression has to be specified, but not both.

An example aspect using @Mixin follows:

   package com.mypackage;

   import org.jboss.aop.Mixin;
   import com.mypackage.POJO;

   @Aspect (scope=org.jboss.aop.advice.Scope.PER_VM)
   public class IntroductionAspect
   {
      @Mixin (target=com.mypackage.POJO.class, interfaces={java.io.Externalizable.class})
      public static ExternalizableMixin createExternalizableMixin(POJO pojo) {
          return new ExternalizableMixin(pojo);
      }
   }
         

Since this is slightly more complex than the previous examples we have seen, the POJO and ExternalizableMixin classes are included here.

   package com.mypackage;

   public class POJO
   {
      String stuff;
   }
      

   package com.mypackage;

   import java.io.Externalizable;
   import java.io.IOException;
   import java.io.ObjectInput;
   import java.io.ObjectOutput;

   public class ExternalizableMixin implements Externalizable
   {
      POJO pojo;

      public ExternalizableMixin(POJO pojo)
      {
         this.pojo = pojo;
      }

      public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException
      {
         pojo.stuff = in.readUTF();
      }

      public void writeExternal(ObjectOutput out) throws IOException
      {
         out.writeUTF(pojo.stuff);
      }
   }
      

This has the same effect as the following XML configuration:

            <introduction classs="com.mypackage.POJO">
            <mixin transient="true">
            <interfaces>
              java.io.Externalizable
            </interfaces>
            <class>com.mypackage.ExternalizableMixin</class>
            <construction>IntroductionAspect.createExternalizableMixin(this)</construction>
            </mixin>
            </introduction>
         

To prepare a joinpoint or a set of joinpoints for DynamicAOP annotate a field with @Prepare in a class anotated with @Aspect or @InterceptorDef.

The declaration of org.jboss.aop.Prepare is:

   package org.jboss.aop;

   @Target({ElementType.FIELD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
         public @interface Prepare {
       String value() default "";
   }
         

The single field value contains a pointcut expression matching one or more joinpoints.

To use @Prepare follow this example:

   package com.mypackage;

   import org.jboss.aop.Prepare;

   @InterceptorDef (scope = Scope.PER_VM)
   @Bind (pointcut="execution("* com.blah.Test->test(..)")
   public class MyInterceptor2 implements Interceptor
   {
      @Prepare ("all(com.blah.DynamicPOJO)")
      public static Pointcut dynamicPOJO;

      public Object invoke(Invocation invocation)throws Throwable
      {
         return invocation.invokeNext();
      }
   }

         

Using XML configuration instead we would write:

            <prepare expr="all(com.blah.DynamicPOJO)"/>
         

This simple example used an @InterceptorDef class for a bit of variety in the examples, and to reiterate that @Pointcut, @Introduction, @Mixin, @Prepare, @Typedef, @CFlow, @DynamicCFlow and @AnnotationIntroductionDef can all be used both in @InterceptorDef annotated classes AND @Aspect annotated classes. Same for @Bind, but that is a special case as mentioned above.

   package com.mypackage;

   import org.jboss.aop.Prepare;

   @Prepare ("all(this)")
   public class MyDynamicPOJO implements Interceptor
   {
      ...
   }
           

            <prepare expr="all(com.blah.MyDynamicPOJO)"/>
           

To summarise, when using @Prepare within an @Interceptor or @Aspect annotated class, you annotate a field within that class. When using @Prepare with a POJO you annotate the class itself.

To use a typedef, you annotate a field with @TypeDef in a class anotated with @Aspect or @InterceptorDef.

The declaration of org.jboss.aop.TypeDef:

package org.jboss.aop;

@Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
public @interface TypeDef {
    String value();
}
         

The single value field takes a type expression that resolves to one or more classes. The name of the typedef used for reference and internally is:

<name of @Aspect/@InterceptorDef annotated class>.<name of @TypeDef annotated field>

Here's how to use it:

   package com.mypackage;

   import org.jboss.aop.TypeDef;
   import org.jboss.aop.pointcut.Typedef;
   @Aspect (scope=org.jboss.aop.advice.Scope.PER_VM)
   public class TypedefAspect
   {
      @TypeDef ("class(com.blah.POJO)")
      public static Typedef myTypedef;

       @Bind (pointcut="execution(* \
             $typedef{com.mypackage.TypedefAspect.myTypedef}->methodWithTypedef())")
       public Object typedefAdvice(Invocation invocation) throws Throwable
      {
         return invocation.invokeNext();
      }
   }
         

The equivalent using XML configuration would be:

            <aop>
            <aspect class="com.mypackage.TypedefAspect" scope="PER>VM"/>
            <typedef name="com.mypackage.TypedefAspect.myTypedef" expr="class(com.blah.POJO)"/>
            <bind
         pointcut="execution(* \
            $typedef{com.mypackage.TypedefAspect.myTypedef}->methodWithTypedef())"
            >
            <advice name="typedefAdvice" aspect="com.mypackage.TypedefAspect"/>
            </bind>
            </aop>
         

To create a CFlow stack, you annotate a field with @CFlowDef in a class anotated with @Aspect or @InterceptorDef. The declaration of org.jboss.aop.CFlowStackDef is:

   package org.jboss.aop;

   @Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
         public @interface CFlowStackDef
   {
      CFlowDef[] cflows();
   }
         

In turn the declaration of org.jboss.aop.CFlowDef is:

   package org.jboss.aop;

   public @interface CFlowDef {
       boolean called();
       String expr();
   }
         

The parameters of @CFlowDef are:

The name of the CFlowStackDef used for reference and internally is:

<name of @Aspect/@InterceptorDef annotated class>.<name of @CFlowStackDef annotated field>

CFlowStackDef is used like the following example:

   package com.mypackage;

   import org.jboss.aop.CFlowStackDef;
   import org.jboss.aop.pointcut.CFlowStack;

   @Aspect (scope=org.jboss.aop.advice.Scope.PER_VM)
   public class CFlowAspect
   {

      @CFlowStackDef (cflows={@CFlowDef(expr= "void com.blah.POJO->cflowMethod1()", \
            called=false),  @CFlowDef(expr = "void com.blah.POJO->cflowMethod2()", \
            called=true)})
      public static CFlowStack cfNot1And2Stack;

      @Bind (pointcut="execution(void com.blah.POJO*->privMethod())", \
            cflow="com.mypackage.CFlowAspect.cfNot1And2Stack")
      public Object cflowAdvice(Invocation invocation) throws Throwable
      {
         return invocation.invokeNext();
      }
   }
         

The above means the same as this XML:

            <aop>
            <cflow-stack name="com.mypackage.CFlowAspect.cfNot1And2Stack">
            <called expr="void com.blah.POJO->cflowMethod1()"/>
            <not-called expr="void com.blah.POJO->cflowMethod2()"/>
            </cflow-stack>
            </aop>
         

To create a dynamic CFlow you annotate a class implementing org.jboss.aop.pointcut.DynamicCFlow with @DynamicCFlowDef. The declaration of @org.jboss.aop.DynamicCFlowDef is:

   package org.jboss.aop;

   @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
   public @interface DynamicCFlowDef
   {
   }
         

Here is a @DynamicCFlow annotated class:

   package com.mypackage;

   import org.jboss.aop.DynamicCFlowDef;
   import org.jboss.aop.pointcut.DynamicCFlow;

   @DynamicCFlowDef
   public class MyDynamicCFlow implements DynamicCFlow
   {
      public static boolean execute = false;

      public boolean shouldExecute(Invocation invocation)
      {
         return execute;
      }
   }
         

The name of the @DynamicCFlowDef annotated class gets used as the name of the cflow for references.

To use the dynamic cflow we just defined:

   package com.mypackage;

   @Aspect (scope=org.jboss.aop.advice.Scope.PER_VM)
   public class CFlowAspect
   {
      @Bind (pointcut="execution(void com.blah.POJO->someMethod())", \
            cflow="com.mypackage.MyDynamicCFlow")
      public Object cflowAdvice(Invocation invocation) throws Throwable
      {
         return invocation.invokeNext();
      }
   }
         

You can introduce annotations by annotating a field with the @AnnotationIntroductionDef in a class anotated with @Aspect or @InterceptorDef. The declaration of org.jboss.aop.AnnotationIntroductionDef is:

   package org.jboss.aop;

   @Target (ElementType.FIELD) @Retention(RetentionPolicy.RUNTIME)
         public @interface AnnotationIntroductionDef
   {
      String expr();
      boolean invisible();
      String annotation();
   }
         

The parameters of @AnnotationIntroductionDef are:

The listings below make use of an annotation called @com.mypackage.MyAnnotation:

   package com.mypackage;
   public interface MyAnnotation
   {
      String string();
      int integer();
      boolean bool();
   }
         

What its parameters mean is not very important for our purpose.

The use of @AnnotationIntroductionDef:

   package com.mypackage;

   import org.jboss.aop.AnnotationIntroductionDef:
   import org.jboss.aop.introduction.AnnotationIntroduction;

   @.InterceptorDef (scope=org.jboss.aop.advice.Scope.PER_VM)
   @org.jboss.aop.Bind (pointcut="all(com.blah.SomePOJO)")
   public class IntroducedAnnotationInterceptor implements Interceptor
   {
      @org.jboss.aop.AnnotationIntroductionDef \
            (expr="method(* com.blah.SomePOJO->annotationIntroductionMethod())", \
             invisible=false, \
             annotation="@com.mypackage.MyAnnotation \
                (string='hello', integer=5, bool=true)")
      public static AnnotationIntroduction annotationIntroduction;

      public String getName()
      {
         return "IntroducedAnnotationInterceptor";
      }

      public Object invoke(Invocation invocation) throws Throwable
      {
         return invocation.invokeNext();
      }
   }
         

Note that the reference to @com.mypackage.MyAnnotation must use the fully qualified class name, and that the value for its string parameter uses single quotes.

The previous listings are the same as this XML configuration:

            <annotation-introduction
      expr="method(* com.blah.SomePOJO->annotationIntroductionMethod())
      invisible="false"
            >
      @com.mypackage.MyAnnotation (string="hello", integer=5, bool=true)
            </annotation-introduction>
         

You can declare precedence by annotating a class with @Precedence, and then annotate fields where the types are the various Interfaces/Aspects you want to sort. You annotate fields where the type is an interceptor with @PrecedenceInterceptor. When the type is an aspect class, you annotate the field with @PrecedenceAdvice. The definitions of org.jboss.aop.Precedence, org.jboss.aop.PrecedenceInterceptor and org.jboss.aop.PrecedenceAdvice are

   package org.jboss.aop;

   @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
   public @interface Precedence
   {
   }
      

   package org.jboss.aop;

   @Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
   public @interface PrecedenceInterceptor
   {
   }
      

   package org.jboss.aop;

   @Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
   public @interface PrecedenceAdvice
   {
      String value();
   }
      

The value() attribute of PrecedenceAdvice is the name of the advice method to use.

The example shown below declares a relative sort order where org.acme.Interceptor must always be invoked before org.acme.Aspect.advice1() which must be invoked before org.acme.Aspect.advice2():

   import org.jboss.aop.Precedence;
   import org.jboss.aop.PrecedenceAdvice;

   @Precedence
   public class MyPrecedence
   {
      @PrecedenceInterceptor
      org.acme.Interceptor intercept;

      @PrecedenceAdvice ("advice1")
      org.acme.Aspect precAdvice1;

      @PrecedenceAdvice ("advice2")
      org.acme.Aspect precAdvice2;
   }
      

The ordering of interceptors/advices defined via annotations that have no precedence defined, is arbitrary.

You can declare checks to be enforced at instrumentation time. They take a pointcut and a message. If the pointcut is matched, the message is printed out. To use this with annotations, annotate fields with DeclareWarning or DeclareError within a class annotated with @Aspect or @InterceptorDef. The definitions of org.jboss.aop.DeclareError and org.jboss.aop.DeclareWarning are:

   package org.jboss.aop;

   @Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
   public @interface DeclareWarning
   {
      String expr();
      String msg();
   }
      

   package org.jboss.aop;

   @Target({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME)
   public @interface DeclareError
   {
      String expr();
      String msg();
   }
      

For both: the expr() attribute is a pointcut expression that should not occur, and the msg() attribute is the message to print out if a match is found for the pointcut. If you use DeclareWarning instrumentation/your application will simply continue having printed the message you supplied. In the case of DeclareError, the message is logged and an error is thrown, causing instrumentation/your application to stop. Here is an example:

   import org.jboss.aop.Aspect;
   import org.jboss.aop.pointcut.Pointcut;
   import org.jboss.aop.DeclareError;
   import org.jboss.aop.DeclareWarning;

   @Aspect (scope=org.jboss.aop.advice.Scope.PER_VM)
   public class DeclareAspect
   {
      @DeclareWarning (expr="class($instanceof{VehicleDAO}) AND \
         !has(public void *->save())", \
         msg="All VehicleDAO subclasses must override the save() method.")
      Pointcut warning;

      @DeclareError (expr="call(* org.acme.businesslayer.*->*(..)) \
         AND within(org.acme.datalayer.*)", \
         msg="Data layer classes should not call up to the business layer")
      Pointcut error;
   }
      

With JBoss AOP you can change advice and interceptor bindings at runtime. You can unregister existing bindings, and hot deploy new bindings if the given joinpoints have been instrumented. Hot-deploying within the JBoss application server is as easy as putting (or removing) a *-aop.xml file or .aop jar file within the deploy/ directory. There is also a runtime API for adding advice bindings at runtime. Getting an instance of org.jboss.aop.AspectManager.instance(), you can add your binding.

      org.jboss.aop.advice.AdviceBinding binding = 
                              new AdviceBinding("execution(POJO->new(..))", null);
      binding.addInterceptor(SimpleInterceptor.class);
      AspectManager.instance().addBinding(binding);

First, you allocated an AdviceBinding passing in a pointcut expression. Then you add the interceptor via its class and then add the binding through the AspectManager. When the binding is added the AspectManager will iterate through ever loaded class to see if the pointcut expression matches any of the joinpoints within those classes.

Any class that is instrumented by JBoss AOP, is forced to implement the org.jboss.aop.Advised interface.

public interface InstanceAdvised
{
   public InstanceAdvisor _getInstanceAdvisor();
   public void _setInstanceAdvisor(InstanceAdvisor newAdvisor);
}

public interface Advised extends InstanceAdvised
{
   public Advisor _getAdvisor();
}

The InstanceAdvisor is the interesting interface here. InstanceAdvisor allows you to insert Interceptors at the beginning or the end of the class's advice chain.

public interface InstanceAdvisor
{
   public void insertInterceptor(Interceptor interceptor);
   public void removeInterceptor(String name);
   public void appendInterceptor(Interceptor interceptor);

   public void insertInterceptorStack(String stackName);
   public void removeInterceptorStack(String name);
   public void appendInterceptorStack(String stackName);

   public SimpleMetaData getMetaData();

}

So, there are three advice chains that get executed consecutively in the same java call stack. Those interceptors that are added with the insertInterceptor() method for the given object instance are executed first. Next, those advices/interceptors that were bound using regular binds. Finally, those interceptors added with the appendInterceptor() method to the object instance are executed. You can also reference stacks and insert/append full stacks into the pre/post chains.

Besides interceptors, you can also append untyped metadata to the object instance via the getMetaData() method.

Dynamic AOP cannot be used unless the particular joinpoint has been instrumented. You can force intrumentation with the prepare functionality

As mentioned, you can add more aspects to a woven class using the org.jboss.aop.InstanceAdvisor. This API is limited to adding interceptors to the existing intereptor chains, so it is a bit limited.

The new default weaving mode introduced in JBoss AOP 2.0.0 still allows you access to the InstanceAdvisor interface, but also offers a fuller instance API, which allows you to add bindings, annotation overrides etc. via the normal dynamic AOP API. This is underdocumented, but for a full overview of the capabilites take a look at how org.jboss.aop.AspectXmlLoader interacts with org.jboss.aop.AspectManager. We are working on a new tidier API for the next version of JBoss AOP. Normally, for dynamic AOP you add things to the top level AspectManager, which means that all instances of all woven classes can be affected.

In JBoss AOP 2.0.0, each aspectized class has its own Domain. A domain is a sub-AspectManager. What is deployed in the main AspectManager is visible to the class's domain, but not vice versa. Furthermore each advised instance has its own Domain again which is a child of the class's domain. The Domain class is a sub-class of the AspectManager, meaning you can add ANYTHING supported by JBoss AOP to it, you are not limited to just interceptors. In the following example we prepare all joinpoints of the POJO class and declare an aspect called MyAspect

   <!-- Weave in the hooks into our POJO class and add the interceptors -->
   <aop>
      <aspect class="MyAspect"/>
      <prepare expr="all(POJO)"/>
   </aop>
   
         

   POJO pojo1 = new POJO();
   POJO pojo2 = new POJO();
   
      

   pojo1.someMethod();
   
      

At this stage, our POJO has the hooks woven in for AOP, but now bindings are deployed, so our call to POJO.someMethod() is not intercepted. Next let us add a binding to POJO's class domain.

   //All woven classes implement the Advised interface
   Advised classAdvisor = ((Advised)pojo1);
   //Get the domain used by all instances of POJO
   AspectManager pojoDomain = classAdvisor._getAdvisor().getManager();
   //Add a binding with an aspect for that class this is similar to
   AdviceBinding binding1 = new AdviceBinding("execution(* POJO->someMethod*(..))", null);
   AspectDefinition myAspect = AspectManager.instance().getAspectDefinition("MyAspect");
   binding1.addInterceptorFactory(new AdviceFactory(myAspect, "intercept"));

   //Add the binding to POJO's domain
   pojoDomain.addBinding(binding1);

   pojo1.someMethod();
   pojo2.someMethod();
      
      

Now we have added a binding to POJO's class Domain. Both calls to someMethod() get intercepted by MyAspect

   //Create an annotation introduction
   AnnotationIntroduction intro = AnnotationIntroduction.createMethodAnnotationIntroduction(
         "* POJO->someMethod()",
         "@MyAnnotation",
         true);

   //Create another binding
   AdviceBinding binding2 = new AdviceBinding("execution(* POJO->@MyAnnotation)", null);
   binding2.addInterceptor(MyInterceptor.class);

   //All woven instances have an instance advisor
   InstanceAdvisor instanceAdvisor1 = ((Advised)pojo1)._getInstanceAdvisor();

   //The instance advisor has its own domain
   Domain pojo1Domain = instanceAdvisor1.getDomain();

   //Add the annotation override and binding to the domain
   pojo1Domain.addAnnotationOverride(intro);
   pojo1Domain.addBinding(binding2);

   pojo1.someMethod();
   pojo2.someMethod();
   
      

We have added an annotation override and a new binding matching on that annotaton to pojo1's domain, so when calling pojo1.someMethod() this gets intercecpted by MyAspect AND MyInterceptor. pojo2.someMethod() still gets intercepted by MyAspect only.

When running JBoss AOP with HotSwap, the dynamic AOP operations may result in the weaving of bytecodes. In this case, the flow control of joinpoints matched only by prepare expressions is not affected before any advices or interceptors are applied to them via dynamic aop. Only then, the joinpoint bytecodes will be weaved to start invoking the added advices and interceptors and, as a result, their flow control will be affected.

On the other hand, if HotSwap is disabled, the joinpoints matched by prepare expressions are completely instrumented and the flow control is affected before classes get loaded, even if no interceptors are applied to them with dynamic aop.

To learn how to enable HotSwap, refer to the "Running Aspectized Application" chapter.

There's nothing really to install if you're running outside the JBoss application server. Just use the libraries under lib/.

To install JBoss AOP in JBoss 4.0.x or JBoss 4.2.x Application Server: with JDK 5, there is an ant build script to install into the application server. It lives in jboss-40-install/jboss-aop-jdk50.deployer/build.xml. Modify jboss-40-install/jboss-aop-jdk50.deployer/jboss.properties to point to the the root of your JBoss installation and specify the application server configuration you want to upgrade. These are the steps taken by the ant script:

JBoss AS 5 ships with AOP 2.0.0.GA. To upgrade to a newer AOP version, we have provided am an script to upgrade the server. It can be found at jboss-50-install/build.xml. Modifly jboss-50-install to point to the root of your JBoss installation, and specify the application server configuration you want to upgrade. These are the steps taken by the ant script:

JBoss AOP works by instrumenting the classes you want to run. This means that modifications to the bytecode are made in order to add extra information to the classes to hook into the AOP library. JBoss AOP allows for two types of instrumentation

This chapter describes the steps you need to take to precompile your classes with the aop precompiler.

JBoss AOP comes with an ant task that you can use for precompiling your classes with the aop precompiler. An example build.xml file is the basis for the explanation.

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

<project default="compile" name="JBoss/AOP">
   <target name="prepare">
         

Define the source directory, and the directory to compile classes to.

         <property name="src.dir" value="PATH TO YOUR SOURCE DIR">
         <property name="classes.dir" value="PATH TO YOUR DIR FOR COMPILED CLASSES">
         

Define also the path of your JBoss AOP installation, as well as the path to the lib directory:

          <property name="jboss.aop.root" value="PATH TO JBOSS AOP HOME"/>
          <property name="jboss.aop.lib" value="${jboss.aop.root}/lib"/>
         

Include the jboss-aop.jar and the jars it depends on in the classpath:

      <path id="classpath">
         <pathelement path="${jboss.aop.lib}/jboss-aop.jar"/>
         <pathelement path="${jboss.aop.lib}/javassist.jar"/>
         <pathelement path="${jboss.aop.lib}/trove.jar"/>
         <pathelement path="${jboss.aop.lib}/jboss-common-core.jar"/>
         <pathelement path="${jboss.aop.lib}/jboss-logging-spi.jar"/>
         <pathelement path="${jboss.aop.lib}/jboss-logging-log4j.jar"/>
         <pathelement path="${jboss.aop.lib}/jboss-mdr.jar"/>
         <pathelement path="${jboss.aop.lib}/jboss-reflect.jar"/>
         <pathelement path="${jboss.aop.lib}/log4j.jar"/>
      </path>
         

As an alternative, you can use the single jar provided with JBoss AOP. This jar bundles all the libraries used by JBoss AOP in a single unit. To use this jar, just define:

      <path id="classpath">
         <pathelement path="${jboss.aop.lib}/jboss-aop-single.jar"/>
      </path>
         

Now, define the org.jboss.aop.ant.AopC ant aop precompiler task:

      <taskdef name="aopc" classname="org.jboss.aop.ant.AopC"
         classpathref="jboss.aop.classpath"/>
      </target>
         

   <target name="compile" depends="prepare">
         

Compile the files (from the source directory to the compiled classes directory):

      <javac srcdir="${src.dir}"
         destdir="${classes.dir}"
         debug="on"
         deprecation="on"
         optimize="off"
         includes="**">
         <classpath refid="classpath"/>
      </javac>
         

Now use the ant aop precompiler task, it reads the files from the classes directory and weaves those classes, ovewriting them with the corresponding weaved version.

      <aopc compilerclasspathref="classpath" verbose="true">
         <classpath path="${classes.dir}"/>
         <src path="${classes.dir}"/>
         <include name="**/*.class"/>
         <aoppath path="jboss-aop.xml"/>
         <aopclasspath path="${classes.dir}"/>
      </aopc>
   </target>
</project>
         

The last tag, aopclasspath, must be used only if you used annotations to configure aspects, bindings, and the like. If this is the case and you are not using a jboss-aop.xml file, you can ommit the aoppath tag. You can also use both annotations and XML to configure aspects. In this case, you must declare both tags. The complete list of the parameters that org.jboss.aop.ant.AopC ant task takes follows:

To run the aop precompiler from the command line you need all the aop jars on your classpath, and the class files you are instrumenting must have everything they would need to run in the java classpath, including themselves, or the precompiler will not be able to run.

The jboss.aop.path optional system property points to XML files that contain your pointcut, advice bindings, and metadata definitions that the precompiler will use to instrument the .class files. The property can have one or files it points to delimited by the operating systems specific classpath delimiter (';' on windows, ':' on unix). Files or Directories can be specified. If it is a directory, JBoss AOP will take all aop.xml files from that directory.

The jboss.aop.class.path optional system property points to all JARs or directories that may have classes that are annotated as @Aspect (See Chapter "Annotated Bindings"). JBoss AOP will browse all classes in this path to see if they are annotated. The property can have one or files it points to delimited by the operating systems specific classpath delimiter (';' on windows, ':' on unix).

It is invoked as:

$java -classpath ... [-Djboss.aop.path=...] [-Djboss.aop.class.path=...] \
                     org.jboss.aop.standalone.Compiler <class files or directories>
         

In the /bin folder of the distribution we have provided batch/script files to make this easier. It includes all the aop libs for you, so you just have to worry about your files. The usage:

$ aopc <classpath> [-aoppath ...] [-aopclasspath ...] [-report] [-verbose] \
      <class files or directories>+
         

The other parameters are the same as above.

There are 3 different modes to run your aspectized applications. Precompiled, loadtime or hotswap. JBoss AOP needs to weave your aspects into the classes which they aspectize. You can choose to use JBoss AOP's precompiler to accomplish this (Compiletime) or have this weavining happen at runtime either when the class is loaded (Loadtime) or after it (HotSwap).

Compiletime happens before you run your application. Compiletime weaving is done by using the JBoss AOP precompiler to weave in your aspects to existing .class files. The way it works is that you run the JBoss AOP precompiler on a set of .class files and those files will be modified based on what aspects you have defined. Compiletime weaving isn't always the best choice though. JSPs are a good instance where compiletime weaving may not be feasible. It is also perfectly reasonable to mix and match compile time and load time though. If you have load-time transformation enabled, precompiled aspects are not transformed when they are loaded and ignored by the classloader transformer.

Loadtime weaving offers the ultimate flexibility. JBoss AOP does not require a special classloader to do loadtime weaving, but there are some issues that you need to think about. The Java Virtual Machine actually has a simple standard mechanism of hooking in a class transformer through the -javaagent. JBoss AOP an additional load-time transformer that can hook into classloading via this standard mechanism.

Load-time weaving also has other serious side effects that you need to be aware of. JBoss AOP needs to do the same kinds of things that any standard Java profiling product needs to do. It needs to be able to process bytecode at runtime. This means that boot can end up being significantly slowed down because JBoss AOP has to do a lot of work before a class can be loaded. Once all classes are loaded though, load-time weaving has zero effect on the speed of your application. Besides boottime, load-time weaving has to create a lot of Javassist datastructure that represent the bytecode of a particular class. These datastructures consume a lot of memory. JBoss AOP does its best to flush and garbage collect these datastructures, but some must be kept in memory. We'll talk more about this later.

HotSwap weaving is a good choice if you need to enable aspects in runtime and don't want that the flow control of your classes be changed before that. When using this mode, your classes are instrumented a minimum necessary before getting loaded, without affecting the flow control. If any joinpoint becomes intercepted in runtime due to a dynamic AOP operation, the affected classes are weaved, so that the added interceptors and aspects can be invoked. As the previous mode, hot swap contains some drawbacks that need to be considered.

JBoss AOP does not require an application server to be used. Applications running JBoss AOP can be run standalone outside of an application server in any standard Java application. This section focuses on how to run JBoss AOP applications that don't run in the JBoss application server.

$ java -cp=<classpath as described above> -Djboss.aop.path=<path to jboss-aop.xml> \
         -Djboss.aop.class.path=aspects.jar
         com.blah.MyMainClass
            

$ java -cp=<classpath as described above> com.blah.MyMainClass
            

$ run-precompiled classpath [-aoppath path_to_aop.xml] [-aopclasspath path_to_annotated] \
      com.blah.MyMainClass [args...]
            

$ java -cp=<classpath as described above> -Djboss.aop.path=<path to jboss-aop.xml> \
      -javaagent:jboss-aop.jar com.blah.MyMainClass
            

$ java -cp=<classpath as described above> -javaagent:jboss-aop.jar \
      com.blah.MyMainClass
            

$ run-load classpath [-aoppath path_to_aop.xml] [-aopclasspath path_to_annotated] \
      com.blah.MyMainClass [args...]
            

$ java -cp=<classpath as described above> -Djboss.aop.path=<path to jboss-aop.xml> \
		-javaagent:jboss-aop.jar=-hotSwap com.blah.MyMainClass
            

$ java -cp=<classpath as described above> -javaagent:jboss-aop.jar=-hotSwap \
		com.blah.MyMainClass
            

$ run-load classpath [-aoppath path_to_aop.xml] [-aopclasspath path_to_annotated] \
		com.blah.MyMainClass [args...]
            

public URL getResource(String name)
public Enumeration<URL> getResources(String name) throws IOException
public Enumeration<URL> getResourceAsStream(String name) throws IOException
            

JBoss AOP is integrated with JBoss 4.0.1+ application server. The integration steps are different depending on what version of JBoss AS you are using and what JDK version you are using. It is also dependent on whether you want to use loadtime or compiletime instrumentation. JBoss 4.x comes with previous versions of JBoss AOP, which can be upgraded to AOP 2.0.x by using the ant scripts as explained in Section 8.2, “Installing with JBoss 4.0.x and JBoss 4.2.x Application Server for JDK 5”. JBoss 5 comes with AOP 2.0.x built in.

Based on what JDK you are on and what loadtime weaving option you want to you, you must configure JBoss AS differently.

<aop xmlns="urn:jboss:aop-beans:1.0">


</aop>
            
            

<?xml version='1.0'  encoding='UTF-8'?>
<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN'
                             'http://java.sun.com/j2ee/dtds/application_1_2.dtd'>

<application>
    <display-name>AOP in JBoss example</display-name>
    <module>
        <java>example.aop</java>
    </module>
    <module>
        <ejb>aopexampleejb.jar</ejb>
    </module>
    <module>
        <web>
           <web-uri>aopexample.war</web-uri>
          <context-root>/aopexample</context-root>
       </web>
   </module>
</application>

			

   <bean name="AspectManager" class="org.jboss.aop.deployers.AspectManagerJDK5">
      ...
      
      <property name="jbossIntegration"><inject bean="AOPJBossIntegration"/></property>

      <property name="enableLoadtimeWeaving">false</property>
      <!-- only relevant when EnableLoadtimeWeaving is true.
           When transformer is on, every loaded class gets
           transformed.  If AOP can't find the class, then it
           throws an exception.  Sometimes, classes may not have
           all the classes they reference.  So, the Suppressing
           is needed.  (i.e. Jboss cache in the default configuration -->
      <property name="suppressTransformationErrors">true</property>
      <property name="prune">true</property>
      <property name="include">org.jboss.test., org.jboss.injbossaop.</property>
      <property name="exclude">org.jboss.</property>
      <!-- This avoids instrumentation of hibernate cglib enhanced proxies
      <property name="ignore">*$$EnhancerByCGLIB$$*</property> -->
      <property name="optimized">true</property>
      <property name="verbose">false</property>
      <!--
         Available choices for this attribute are:
            org.jboss.aop.instrument.ClassicInstrumentor (default)
            org.jboss.aop.instrument.GeneratedAdvisorInstrumentor
       <property name="instrumentor">org.jboss.aop.instrument.ClassicInstrumentor</property>
      -->
          <!-- 
                By default the deployment of the aspects contained in 
                ../deployers/jboss-aop-jboss5.deployer/base-aspects.xml
                are not deployed. To turn on deployment uncomment this property
          <property name="useBaseXml">true</property>
          -->
   </bean>

               
            

   <mbean code="org.jboss.aop.deployment.AspectManagerServiceJDK5"
      name="jboss.aop:service=AspectManager">
      <attribute name="EnableLoadtimeWeaving">false</attribute>
      <!-- only relevant when EnableLoadtimeWeaving is true.  
           When transformer is on, every loaded class gets 
           transformed.  If AOP can't find the class, then it 
           throws an exception.  Sometimes, classes may not have 
           all the classes they reference.  So, the Suppressing 
           is needed.  (i.e. Jboss cache in the default configuration -->
      <attribute name="SuppressTransformationErrors">true</attribute>
      <attribute name="Prune">true</attribute>
      <attribute name="Include">org.jboss.test, org.jboss.injbossaop</attribute>
      <attribute name="Exclude">org.jboss.</attribute>
      <!-- This avoids instrumentation of hibernate cglib enhanced proxies
      <attribute name="Ignore">*$$EnhancerByCGLIB$$*</attribute> -->
      <attribute name="Optimized">true</attribute>
      <attribute name="Verbose">false</attribute>
      <depends optional-attribute-name="JBossIntegrationWrapper" proxy-type="attribute">jboss.aop:service=JBoss4IntegrationWrapper</depends>
      <!-- 
         Available choices for this attribute are:
            org.jboss.aop.instrument.ClassicInstrumentor (default)
            org.jboss.aop.instrument.GeneratedAdvisorInstrumentor
       <attribute name="Instrumentor">org.jboss.aop.instrument.ClassicInstrumentor</attribute>
      -->
   </mbean>

               
            

By default all deployments in JBoss are global to the whole application server. That means that any ear, sar, jar etc. that is put in the deploy directory can see the classes from any other deployed archive. Similarly, aop bindings are global to the whole virtual machine. This "global" visibility can be turned off per top-level deployment.

<jboss-app>
  <loader-repository>
      jboss.test:service=scoped
  </loader-repository>
</jboss-app>

<?xml version="1.0" encoding="UTF-8"?>
<aop>
   <loader-repository>jboss.test:service=scoped</loader-repository>

   <!-- Aspects and bindings -->
</aop>

The aop compile plugin is configured to run after the default maven compile phase has ended. By default it will try to find the jboss-aop.xml file in src/main/resources/jboss-aop.xml. It will also try to weave every class in $project.build.outputDirectory (usually target/classes). List of options:

There are a lot of options that can be set, but noone are mandatory (if they are mandatory they have a default value set). The average user would most likely only change aoppaths. A more complete example would look like:

<plugin>
  <groupId>org.jboss.maven.plugins</groupId>
  <artifactId>maven-jbossaop-plugin</artifactId>
  <version>1.0</version>
  <executions>
    <execution>
      <id>compile</id>
      <configuration>
      <!-- if you want to include dependencies from the current module
           (only needed if a class inherits a class thats not defined in this module
           -->
        <includeProjectDependency>true</includeProjectDependency>
        <aoppaths>
          <aoppath>src/main/resources/jboss-aop_test2.xml</aoppath>
          <!-- for a second jboss-aop.xml file
          <aoppath>src/main/resources/jboss-aop.xml</aoppath>
          -->
        </aoppaths>
        <!-- You can specify to only aopc a specific set of classes 
        <includes>
          <include>POJO.class</include>
        </includes>
        -->
      </configuration>
      <goals>
        <goal>compile</goal>
      </goals>
    </execution>
  </executions>
</plugin> 

The only difference between aop compiling tests and non-tests are the name of the plugin. The options are the same for tests and non-tests. A quick example:

<plugin>
  <groupId>org.jboss.maven.plugins</groupId>
  <artifactId>maven-jbossaop-plugin</artifactId>
  <version>1.0</version>
  <executions>
    <execution>
      <id>compile-test</id>
      <configuration>
        <aoppaths>
          <aoppath>src/main/resources/jboss-aop_testcase.xml</aoppath>
        </aoppaths>
      </configuration>
      <goals>
        <goal>compile-test</goal>
      </goals>
    </execution> 
  </executions>
</plugin> 

JBoss aop run plugin is configured to run after the package phase. There are less options here than for the compile step and they are very similar.

A small example using default jboss-aop.xml:

<plugin>
  <groupId>org.jboss.maven.plugins</groupId>
  <artifactId>maven-jbossaop-plugin</artifactId>
  <version>1.0.CR1</version>
  <executions>
    <execution>
      <id>run</id>
      <configuration>
        <executable>Foo</executable>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution> 
  </executions>
</plugin> 

Running a java application in loadtime weaving is almost identical to compile time (except that you dont need to precompile it first). The only change is that we need an option to say that we want to run it loadtime.

A small example:

<plugin>
  <groupId>org.jboss.maven.plugins</groupId>
  <artifactId>maven-jbossaop-plugin</artifactId>
  <version>1.0.CR1</version>
  <executions>
    <execution>
      <id>run</id>
      <configuration>
        <aoppaths>
          <aoppath>src/main/resources/jboss-aop_testcase.xml</aoppath>
        </aoppaths>
        <loadtime>true</loadtime>
        <executable>Test</executable>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution> 
  </executions>
</plugin> 

Running tests with aop is a different matter since the maven tests plugin is rather complex. But we can add the hooks we need to run it both compiletime and loadtime with the maven tests too. An example on how to run a test thats been aop compiled:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.4</version>
  <configuration>
    <forkMode>always</forkMode>
    <useSystemClassLoader>true</useSystemClassLoader>
    <argLine>-Djboss.aop.path=src/main/resources/jboss-aop_testcase.xml</argLine>
  </configuration>
</plugin> 

To run it loadtime we only need to add the javaagent option to argLine. Like this:

    <argLine>-javaagent:${settings.localRepository}/org/jboss/jboss-aop/2.0.0.CR3/\
    jboss-aop-2.0.0.CR3.jar \
    -Djboss.aop.path=src/main/resources/jboss-aop_testcase.xml</argLine> 

- big thanks to henrik and finn for figuring out how to do this :) Note again that the versions used here are just for a reference and to provide as examples. Check the JBoss AOP homepage for the up-to-date versions.

To address the issues with interceptors not being invoked when you use reflection, we have provided a reflection aspect. You bind it to a set of caller pointcuts, and it mounts the pre-defined interceptor/aspect chains. The jboss-aop.xml entries are:

    
   <aspect class="org.jboss.aop.reflection.ReflectionAspect" scope="PER_VM"/>

   <bind pointcut="call(* java.lang.Class->newInstance())">
      <advice name="interceptNewInstance" \
         aspect="org.jboss.aop.reflection.ReflectionAspect"/>
   </bind>

   <bind pointcut="call(* java.lang.reflect.Constructor->newInstance(java.lang.Object[]))">
      <advice name="interceptNewInstance" \
         aspect="org.jboss.aop.reflection.ReflectionAspect"/>
   </bind>

   <bind pointcut="call(* java.lang.reflect.Method->invoke(java.lang.Object, java.lang.Object[]))">
      <advice name="interceptMethodInvoke" \
         aspect="org.jboss.aop.reflection.ReflectionAspect"/>
   </bind>

   <bind pointcut="call(* java.lang.reflect.Field->get*(..))">
      <advice name="interceptFieldGet" \
         aspect="org.jboss.aop.reflection.ReflectionAspect"/>
   </bind>

   <bind pointcut="call(* java.lang.reflect.Field->set*(..))">
      <advice name="interceptFieldSet" \
         aspect="org.jboss.aop.reflection.ReflectionAspect"/>
   </bind>   

         

The ReflectionAspect class provides a few hooks for you to override from a subclass if you like. These methods described below.

   protected Object interceptConstructor(
		Invocation invocation,
		Constructor constructor,
		Object[] args)
		throws Throwable;
         

Calls to Class.newInstance() and Constructor.newInstance() end up here. The default behavior is to mount any constructor execution or caller interceptor chains. If you want to override the behaviour, the parameters are:

   protected Object interceptFieldRead(
      Invocation invocation,
      Field field,
      Object instance)
      throws Throwable;
         

Calls to Field.getXXX() end up here. The default behavior is to mount any field read interceptor chains. If you want to override the behaviour, the parameters are:

   protected Object interceptFieldWrite(
      Invocation invocation,
      Field field,
      Object instance,
      Object arg)
      throws Throwable;
         

Calls to Field.setXXX() end up here. The default behavior is to mount any field write interceptor chains. If you want to override the behaviour, the parameters are:

   protected Object interceptMethod(
		Invocation invocation,
		Method method,
		Object instance,
		Object[] args)
		throws Throwable;
         

Calls to Method.invoke() end up here. The default behavior is to mount any method caller interceptor chains (method execution chains are handled correctly by default). If you want to override the behaviour, the parameters are:

The ReflectionAspect also helps with getting rid of the JBoss AOP "plumbing" information. You bind it to a set of caller pointcuts, using the followingjboss-aop.xml entries :

   
   <bind pointcut="call(* java.lang.Class->getInterfaces())">
      <advice name="interceptGetInterfaces" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getDeclaredMethods())">
      <advice name="interceptGetDeclaredMethods" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getDeclaredMethod(..))">
      <advice name="interceptGetDeclaredMethod" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getMethods())">
      <advice name="interceptGetMethods" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getMethod(..))">
      <advice name="interceptGetMethod" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getDeclaredFields())">
      <advice name="interceptGetDeclaredFields" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getDeclaredClasses())">
      <advice name="interceptGetDeclaredClasses" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

   <bind pointcut="call(* java.lang.Class->getDeclaredField(..))">
      <advice name="interceptGetDeclaredField" \
         aspect="org.jboss.test.aop.reflection.ReflectionAspectTester"/>
   </bind>

         

This way the calls to Class.getMethods() etc. only return information that is present in the "raw" class, by filtering out the stuff added to the class by JBoss AOP.

To achieve array interception we need to replace all access to arrays within a selected set of classes. The arrayreplacement element is used for this. You can either specify a particular class using the class attribute or a class expression using the expr attribute:

    
   <arrayreplacement class="org.acme.POJOWithArray"/>
   <arrayreplacement expr="class(org.acme.*)"/>

         

If we want to intercept an array's elements, that array field needs to be woven, using either a prepare or a bind expression. If that field is within a class picked out by an arrayreplacement expression it gets all the hooks for arrayreplacement to take place. The following xml along with the previous arrayreplacement weaves org.acme.POJOWithArray.ints for array element interception.

    
   <prepare expr="field(int[] org.acme.POJOWithArray->ints)"/>

         

To bind advices to the access of array elements, you use a arraybind element. It binds advices to all arrays woven for array access. You can use the type attribute to specify if you want the interception to take place when setting elements in the array, getting elements from the array, or both. Valid values for the type attribute are: READ_WRITE, READ_ONLY and WRITE_ONLY. An example is shown below:

    
   <interceptor class="org.acme.TestInterceptor"/>
   <arraybind type="READ_ONLY">
      <interceptor-ref name="org.acme.TestInterceptor"/>
   </arraybind>

         

arraybind currently only supports interceptor-ref and advice as child elements. before, after, throwing and finally are not yet supported for array interception. for arrays.

Writing aspects for array element interception is more or less the same as for any other joinpoint. However, array element interception comes with its own hierarchy of Invocation clases. Which one of these is used depends on what is being itercepted. The hierarchy is shown below (all the classes live in the org.jboss.aop.array package):

    
ArrayElementInvocation
-ArrayElementReadInvocation
--BooleanArrayElementReadInvocation  -Element read from a boolean[]
--ByteArrayElementReadInvocation     -Element read from a byte[]
--CharArrayElementReadInvocation     -Element read from a char[]
--DoubleArrayElementReadInvocation   -Element read from a double[]
--FloatArrayElementReadInvocation    -Element read from a float[]
--IntArrayElementReadInvocation      -Element read from a int[]
--LongArrayElementReadInvocation     -Element read from a long[]
--ObjectArrayElementReadInvocation   -Element read from a Object[], String[] etc.
--ShortArrayElementReadInvocation    -Element read from a shore[]
-ArrayElementWriteInvocation
--BooleanArrayElementWriteInvocation -Element written to a boolean[]
--ByteArrayElementWriteInvocation    -Element written to a byte[]
--CharArrayElementWriteInvocation    -Element written to a char[]
--DoubleArrayElementWriteInvocation  -Element written to a double[]
--FloatArrayElementWriteInvocation   -Element written to a float[]
--IntArrayElementWriteInvocation     -Element written to a int[]
--LongArrayElementWriteInvocation    -Element written to a long[]
--ObjectArrayElementWriteInvocation  -Element written to a Object[], String[] etc.
--ShortArrayElementWriteInvocation   -Element written to a short[]

         

The write invocation classes allow you access to the value the element is being set to. ArrayElementReadInvocation defines a method to get hold of the value being set:

   public abstract Object getValue();    

         

The sub-classes override this value, and also define a more fine-grained value to avoid using the wrapper classes where appropriate, as shown in the following methods from DoubleArrayElementWriteInvocation:

   public Object getValue()
   {
      return new Double(value);
   }

   public double getDoubleValue()
   {
      return value;
   }

         

When reading an array element the invocation's return value contains the value read. For all array invocations you can get the index of the element being accessed by calling ArrayElementInvocation.getIndex().

This original weaving mode offers the full basic functionality, and comes in two flavours: 'non-optimized' and 'optimized'.

   <aopc optimized="false" compilerclasspathref="...">
      <sysproperty key="jboss.aop.instrumentor" \
         value="org.jboss.aop.instrument.ClassicInstrumentor"/>
      ...
   </aopc>
                  
         

   java -Djboss.aop.optimized=false \
      -Djboss.aop.instrumentor=org.jboss.aop.instrument.ClassicInstrumentor \
      [other aop and classpath settings] MyClass
         

   <aopc optimized="true" compilerclasspathref="...">
      <sysproperty key="jboss.aop.instrumentor" \
         value="org.jboss.aop.instrument.ClassicInstrumentor"/>
      ...
   </aopc>
                  
         

   java -Djboss.aop.optimized=true \
      -Djboss.aop.instrumentor=org.jboss.aop.instrument.ClassicInstrumentor \
      [other aop and classpath settings] MyClass
         

This is the weaving mode that is used by default in JBoss AOP 2.0.x. In addition to generating the invocation classes, it also generates the 'advisors'. These contain the internal book-keeping code that keeps track of the advice chains for the varoius woven joinpoints). At runtime, this means that there is less overhead of looking things up. This mode also allows for some new features in JBoss AOP 2.0.x.

This weaving mode is used by default, so you don't have to specify any extra parameters. This may change in future, so for completeness the parameter you would to pass in to the aopc ant task is.

An example is shown in the following build.xml snippet. Only the relevant parts are shown.

   <aopc optimized="true" compilerclasspathref="...">
      <sysproperty key="jboss.aop.instrumentor" \
         value="org.jboss.aop.instrument.GeneratedAdvisorInstrumentor"/>
      ...
   </aopc>
                  
      

Similarly, for load-time weaving, the default is to use this weaving mode. If you were to need to turn it one you would pass in the GeneratedAdvisorInstrumentor when starting the JVM:

   java -Djboss.aop.instrumentor=org.jboss.aop.instrument.GeneratedAdvisorInstrumentor \
      [other aop and classpath settings] MyClass
      

Now we will look at some of the features that are available using this weaving mode.

   public class Base{
      void test(){}
   }

   public class Child{
   }

   public class ChildTest{
      void test(){}
   }
               
         

   <aop>
      <prepare expr="execution(* POJO->test())"/>
      <bind pointcut="execution(* Base->test())">
         <interceptor class="BaseInterceptor"/>
      </bind>
      <bind pointcut="execution(* Child*->test())">
         <interceptor class="ChildInterceptor"/>
      </bind>
   </aop>
   
         

Base base = new Base();                  //1
Child child = new Child();               //2
ChildTest childTest = new ChildTest();   //3

base.test();                             //4
child.test();                            //5
childTest.test();                        //6