A little while ago I released JBoss AOP 1.5.2 which is a maintenance release - the main aim of this was to unify the integration of JBoss AOP 1.5.x and JBoss AOP 2.x with JBoss 4. JBoss AOP 1.5.2 will be included in the upcoming JBoss 4.0.5 release, and is the current production release.

More interestingly JBoss AOP 2.0.0.alpha1 was released last week. It contains some interesting new features, many of which are enabled by our brand new weaving model. More features are scheduled for alpha2. These releases can be downloaded from the main JBoss AOP download page, please try the 2.0.0 alpha and give feedback via our user forum. Special thanks to Ståle W Pedersen for all his help with tasks that have gone into this release.

I'll now talk a little about the most interesting new features in JBoss AOP 2.0.0 alpha1.

Improved Instance API

The JBoss AOP model is completely dynamic. As long as your classes are "prepared" (i.e. have the hooks for AOP woven into them), you can add new aspects, bindings, metadata, annotation overrides etc. on the fly. This is done on the AspectManager singleton, which is the central storage for all this information. Whether you deploy your AOP using a jboss-aop.xml file or annotation, the AspectXmlLoader or AspectAnnotationLoader will translate the configuration data into calls to add the bindings, aspect definitions etc to the AspectManager singleton. All instances of woven classes which match some of these bindings then have their advice chains etc. updated.

JBoss AOP 1.x has a coarse-grained per instance API, which allows you to add interceptors (An interceptor is a special kind of aspect) either before or after the interceptor chain created by the data from the AspectManager, but that is more or less what you can do. This is what the Pojo Cache does when you add an object instance to the cache; for all fields that are prepared, it adds some interceptors to that instance to access the data from the cache instead of from the fields, effectively giving us a POJO with clustered state.

In JBoss AOP 2.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. An example probably illustrates this better.

   <!-- 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
    * <bind pointcut="execution(* POJO->someMethod*(..))"/>
    *    <advice aspect="MyAspect" name="intercept"/>
    * </bind>
    */
   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

Scoped AOP

We have had some support for this since JBoss AOP 1.5.0, but the way this works has been improved a lot.

Background

As you may know JBoss Application Server has a class loading model that gives you total visibility of classes across the whole application server. So if you have two ear files deployed, classes in one ear files use classes from the other ear file. In most cases this is great news since this means that you only need to make classes available once and everybody can see them. Also it means you avoid the overhead of call by value when making calls between the two ear files, which is great for performance.

In JBoss every single top-level deployment gets its own class loader, and this class loader is part of a class loader domain. All class loaders within the same class loading domain can see classes from loaders belonging to the same class loading domain. The way this works is that a class loading domain is backed by a repository. When a class loader is asked to load a class it checks with the repository for the class definition first to see if the class has already been loaded by another class loader within the domain.

In some cases, though, this global visibility is not what you want. You may want to for example deploy two different versions of your application, with the same classes but with say a development version and a production version. To do this you need to scope your deployment. The class loader created for a scoped deployment belongs to a child domain of the global class loader domain. It can still access classes from the global domain, but the classes in the scoped deployment are invisible from outside that deployment.

We can deploy development.ear and production.ear, which contain different versions of the same classes, as scoped deployments. If they both contain a class called Person, whenever we try to load up Person from within development.ear we get the copy deployed in development.ear, and whenever we try to load up Person from with in production.ear we get production.ear's Person copy.

The real deal

We can do exactly the same for aspects. Up until now, whenever aspects and bindings are deployed they have been deployed globally to the whole application server instance meaning that the aspects and bindings are applied to all matched classes within all deployments on the server. If you deploy your aspects directly into the server/xxx/deploy folder this is still what will happen.

However, if you package your aspects into a .aop archive containing a jboss-aop.xml file (we still need to make this work for the annotation based deployment model), and package that .aop file into a scoped deployment we get scoped aop. Meaning the aspects and bindings contained in the scoped deployment only apply to that particular deployment. So, you could have two scoped deployments being aspectized in different ways. And of course the scoped deployments can use the "global" aspects and bindings.

Same rules for inherited methods as for overridden methods

Consider the following case:

public class Base{
   void test(){}
}
 
public class Child{
}
 
public class ChildTest{
   void test(){}
}
 
---
<aop>
   <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

With the "old" weaving we needed an exact match on methods for advices to get bound, meaning that:

• Call 4 would get intercepted by BaseInterceptor
• Call 5 would get intercepted by BaseInterceptor
• Call 6 would get intercepted by ChildInterceptor

The discrepancy is between calls 5 and 6, we get different behaviour depending on if we have overridden the method or are just inheriting it, which in turn means we have to have some in-depth knowledge about our hierarchy of classes and who overrides/inherits what in order to have predictable interception.

The new weaving model matches differently, and treats inherited methods the same as overridden methods, so:

• Call 4 would get intercepted by BaseInterceptor
• Call 5 would get intercepted by ChildInterceptor
• Call 6 would get intercepted by ChildInterceptor

Upcoming features

I'll keep this section short and post more once these features have bee have been released properly - some of these exist in the current alpha 1 release, but need polishing.

Before/After/Throwing support

JBoss AOP has always used around advices, and you can get all the functionality offered by before/after/throwing from an around advice. The main overhead of an around advice is that for every called aspectized joinpoint we need to allocate an instance of an invocation object to drive the chain of advices. With Before/After/Throwing advices there is no invocation object needed, so there will be some performance gains here.

Microcontainer integration

A lot of work has been done this year to integrate the upcoming JBoss Microcontainer 2.0 with JBoss AOP. Part of what this allows is:

• Managed aspects - These are aspects managed as beans by the microcontainer, which can have dependencies on other MC beans, and can have these dependencies injected.
• Dependencies - If a bean has aspects applied to it, and those aspects have dependencies, those dependencies become part of the bean's dependencies
• Per-instance metadata - MC beans can have metadata attached to them at instance-level and this can be used to determine whether a particular bean instance should be aspectized or not.

The Microcontainer will be the core of JBoss 5