The second part of our article series about JRockit JVM support for AOP is now published.

This article describes in more detail on how the API is used, showing some code samples and ends with a discussion in which we try to explain how we address the questions and issues (around the shortcomings of bytecode manipulation) raised in part one in the series.

The prototype will be downloadable soon, stay tuned.

Writing multi-threaded applications in Java can as you know be quite tricky, and if not done correctly, one can easily end up with deadlock situations.

For example, take a look at this little code snippet. This piece of Java code implements a Node, which has three methods (that is of our interest):

Object get() , void set(Object o) and void swap(Node n)

Here's the implementation: public class Node { private Object value; public synchronized Object get() { return value; } public synchronized void set(Object value) { this.value = value; } public synchronized void swap(Node n) { Object tmp = get(); set(n.get()); n.set(tmp); } ... // remaining methods omitted }

This class might look okay, but it actually suffers from potential deadlock. For example what happens if, one thread T1 invokes n1.swap(n2) while an other one T2 concurrently invokes n2.swap(n1) ?

Thread T1 acquires the lock for node n1, and thread T2 acquires the lock for node n2. Thread T1 now invokes n2.get() (in the swap(..) method). This invocation now has to wait since node n2 is locked by thread T2, this while the reverse holds for thread T2 (e.g. it needs to wait for node n1 which is locked by thread T1). Which means that we have a deadlock.

This program is however easily fixed by using the technique of totally ordering all objects in the system.

public class Node { private Object value; public synchronized Object get() { return value; } public synchronized void set(Object value) { this.value = value; } private synchronized void doSwap(Node n) { Object tmp = get(); set(n.get()); n.set(tmp); } public void swap(Node n) { if (this == n) { return; } else if (System.identityHashCode(this) < System.identityHashCode(n)) { doSwap(n); } else { n.doSwap(this); } } ... // remaining methods omitted }

In this program, all locks will be acquired in increasing order, guaranteed to be the same for all threads, and thereby avoiding deadlock situations.

Currently you can for example pick out a call to a method that is declared as being synchronized and you can pick out calls to Thread:: notify()/notifyAll()/wait(). Meaning that being able to pick out synchronized blocks are the only missing piece left in order to completely control thread management and locking in Java. The actual bytecode modifications needed to make this work would be fairly simple, but capturing the correct semantics in a good language design would probably be a lot trickier.

Well, I'm not a language designer, but I think the problem is interesting so I will spend some time discussing it anyway.

In bytecode, a synchronized block is represented as a MONITOR ENTRY and a MONITOR EXIT bytecode instruction pair (however these are not required to be paired). The first natural approach would to let these two bytecode instructions be join points and treat them similar to field access and modification (PUTFIELD and GETFIELD bytecode instructions), meaning simply pick out (and intercept) this single bytecode instruction.

Just to clarify what I mean, here is an example of how the syntax for the above given semantics could look in the AspectJ pointcut expression language:

lock(Type t) && withincode(* Foo.bar(..)) && args(t)

unlock(Type t) && withincode(* Foo.bar(..)) && args(t)

Let us take a look at a synchronized block and how it would be affected:

synchronized(obj) {
    // body
}

In bytecode to this is equivalent to (pseudo code):

MONITOR ENTRY // lock on obj
    // body
MONITOR EXIT

If we now add around advices to these join points then we could for example get (pseude code):

try {
    // a call to the around advice, which calls the lock manager
    aroundAdvice1(obj) --> myLockManager.acquire(obj); 

    // body

} finally {
    aroundAdvice2(obj) --> myLockManager.release(obj);
}

This approach would give you the possibility to completely control how locking is done in Java (including the possibility of enhancing or completely screw up the Java Memory Model (JMM)). On the other hand it does not allow you to pick out the actual code block that is synchronized (is this something that we want?) . Therefore this approach is perhaps not intuitive, since in Java source code, what we see is not lock acquisition and release but a code block that is guaranteed to be synchronized. So now let's try to approach this problem from the perspective of source code.

Since AspectJ (and AspectWerkz) already has limited support for the synchronized keyword by allowing calls to methods declared as being synchronized to be matched, let us take a look at the semantics for this join point.

Here's a simple method that is defined as being synchronized:

public synchronized void doStuff() { 
    // body
}

What this actually means is:

public void doStuff() { 
    synchronized(this) {
        // body
    }
}

The options we have of picking up this synchronized code block (wrapped up in the doStuff() method) is by using a

execution(synchronized void *.doStuff())

call(synchronized void *.doStuff())

Using the execution pointcut, the above method body would be transformed to (pseudo code):

synchronized(this) {
    // the advice has option of invoking the original body
    myAroundAdvice(this) 
}

I.e. only synchronized body is matched and intercepted.

If we are using the call pointcut, the same code snippet would be transformed to (pseudo code):

...
// the advice has the option of invoking the original synchronized block
myAroundAdvice(this) 
...

I.e. the whole synchronized block, including the locking is matched (and intercepted). (This is conceptionally true, in regards to the locking, which is easy to see if you think of the doStuff() method as being inlined.)

I will not go into much detail about how these semantic differences should be expressed in the pointcut language here (this post is too long already). But for example, the last discussion would require the possibility of making a distinction between picking out a code block inclusively and exclusively (i.e. picking out the whole code block, or just the body of the code block), which could be expressed something like this:

// pick out synchronized block including the locking
block-inclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t)

// pick out only the synchronized block's body, not the locking
block-exclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t) 

(These "block" pointcut descriptors can of course be used in any kind of block, loops, conditional statements etc., if/whenever they are supported in AspectJ.)

To sum up, the questions are: Do we want the power of intercepting the whole locking mechanism (but not the synchronized body), or is it better to follow the semantics we have for a synchronized method? Which approach addresses the use cases we want? Is the most intuitive? Is more orthogonal?

Thoughts? Comments? Ideas?

Terracotta just recently launched a product (DSO) for clustering POJOs in a completely transparent way. What I find interesting in this product is not mainly in the clustering and caching, but how they make use of AOP and loadtime weaving to make it completely transparent.

This sounds a lot like techniques that we have been working on in AspectWerkz last years, and I was not too surprised, although very happy, to learn that they are actually using AspectWerkz. It is really great to see some of the ideas that Alex and I have been working on being used in new and interesting ways and in real-world applications.

They seem to use techniques that are fairly similar to the Unit of Work aspect library that I wrote for the AWare aspect library. Meaning: record field changes to object graphs within a transaction which can be committed/rolled back./etc. add specific methods that are defined declaratively.

However they have extended to this idea by adding semantics currently not available in AOP. For example being able to pick out synchronized blocks. This is a great idea, and when you think of it, it is in a way a hole in the current AOP implementations. Currently you can for example pick out a call to a method that is declared as being synchronized and you can pick out calls to Thread:: notify()/notifyAll()/wait(). Meaning that being able to pick out synchronized blocks are the only missing piece left in order to completely control thread management and locking in Java. The actual bytecode modifications needed to make this work would be fairly simple, but capturing the correct semantics in a good language design would probably be a lot trickier.

All and all a very interesting product that shows the beauty of AOP and loadtime weaving in action, go and check it out.

/Jonas

If you're interested in knowing more about what the future holds for AOP, then you should come to the technical session TS-7659 (titled "Runtime Aspects With JVM Support") on Tuesday, June 28 at JavaOne 2005.

This will be the first time ever to show an enterprise JVM - BEA JRockit - with native AOP support. Alex Vasseur and myself have been pushing for this idea since the early days of AspectWerkz when we joined the JRockit group, and it's finally taking shape, with now support for AspectJ 5, the de-facto standard for AOP in Java.

Credit should also go to Joakim Dahlstedt, the CTO of JRockit, who has been playing a leading role in the design and implementation.

We will talk about the current problems with bytecode based weaving (multiple agents, double bookkeeping, performance etc.) and then discuss how these problems can be solved through native JVM support. We will show a prototype of our implementation, go through the programming model and run a live demo.

Here is the abstract:

"Aspect Oriented Programming (AOP) is growing in popularity. Adding aspects at runtime, dynamic weaving, can be a very powerful technique for diagnostics, profiling, or debugging of a running system. The concept of adding aspects at runtime (dynamic weaving) is looked upon with skepticism by some. It's also easy for multiple instrumenting agents to cause havoc for each other. We have implemented prototype changes to our Java™ Virtual Machine (JVM™ software), BEA Weblogic JRockit, to support dynamic weaving in the JVM software in a controlled fashion. We also have modified AspectJ 5 to try out this functionality. We believe our changes to the JVM software to support dynamic weaving lessens the skepticism about runtime aspects and allows for multiple instrumenting agents to coexist.
In this session we present the changes we made to the JVM software to support this functionality and the results of this effort. In addition, we compare this approach to current approaches like JVMTI/Hotswap and Project JFluid. Finally, we provide a demonstration of various runtime advice you'll find useful to analyze the behavior of your applications."

Don't miss it, see you there.

I just got back from the Nordic Software Developer Summit (Nordev) 2005. Strange enough, this is the first good developer conference that we have had in Sweden.

Altogether it was a really good event with two major tracks, one Java and one .Net. The Java track had interesting talks on topics like: AOP :-), agile development, hibernate, spring, manageability of the JRockit JVM etc. (e.g. the usual suspects).

I was glad to see that AOP got a lot of focus with talks from myself and Rickard Oberg and a hands-on workshop (on AspectJ). Both sessions were packed, and people seemed enthusiastic about it.

Of all things you can be nervous about, I was nervous about speaking in Swedish (my native language). I had never spoken about AOP in Swedish so it was interesting and a good exercise :-). Everything went pretty well except that eclipse died on me when I was starting up the demo (3.1 M6). (The demo was about how to write a unit of work to achieve transparent persistence/replication/transaction management, perhaps something for an upcoming blog post...).

I enjoyed Rickard's talk. He based the talk on examples from the CMS application and he has built, and it was interesting to see both simple and advanced usage of AOP in the real world application. He's using a pretty extreme approach to AOP in which every single object is built up a using intertype declarations (introductions/mixins). I do not think that this model fits every project, and it for sure has drawbacks, but in their CMS application it has given them extremely high reuse and development speed.

He showed examples of client aspects, how objects can render themselves differently based on which intertype declarations it has. For example, if an object in their GUI (a page, a site, a portlet etc.) has the intertype declaration ACL applied to it then it will give you the possibility to open up a window to manage security for this object. This object can also be given the Tree intertype declaration, which will allow you to browse the object in a tree structure etc.

He also showed examples on how they do client synchronization and cluster wide replication, using the same aspect (which simply records the events triggered and then plays it back). Another interesting aspect that they have is what he calls partial object versioning, in which intertype declarations can be versioned and different versions can be used (in the same object), depending on how system is configured.

Rickard gave an example of a customer that came in with a new functional requirements very late in the release cycle, requirements that required redesign of some parts of the system, but that he managed to solve in a simple and generic way by applying an aspect.

Then he talked about the need for tools and that most problems that people are complaining about when it comes to AOP are actually not related to AOP, but to the lack of good tools. He showed one interesting tool that they are using on a daily basis, a tool for doing a diff of the system. This diff showed you which advice and or intertype declarations had been removed or added since the last time the system's state was recorded. For example, after a regular refactoring, the diff should be zero. This is something that we should add to AJDT.

All and all a good conference, you should try to get there next year.

The upcoming release of JRockit will contain a new, completely killing, tool for memory leak detection.

It allows you to (among many other things) to profile an application running in production with (almost) zero overhead (without shutting it down or any preparation whatsoever).

Bill Burke and Dion Almaer has already blogged about it.

If you are interested to find out more, we have set up a webinar demo that anyone can join. Drop me an email at [jboner AT gmail DOT com] and I will send you the 'dial in info'.

------
Update: here is the dial in info (no need to mail me):

---------------------------- Web Meeting ---------------------------------
When: Wednesday, March 23, 2005 10:00 AM-11:00 AM (GMT-07:00) Arizona. 
Where: Dial In/Web Meeting 
Web Meeting Address:            https://www.webmeeting.att.com
Toll Free Dial In Number:               (866)214-3176
Int'l Access/Caller Paid Dial In Number:                (404)827-9098
ACCESS CODE:             5519740
--------------------------------------------------------------------------------

AOSD 2005 has just started. I am excited, and have high expectations since last years conference was a real hit, and this year we have a separate industry track with many interesting talks coming up, f.e. Grady Booch is doing a keynote.

I will be giving a talk on AspectWerkz 2 and the road to AspectJ 5 at the AOSD 2005 conference hosted at the Intercontinental hotel in Chicago.

If you are in the area, please drop in and say hi.

If you are interested you can read the abstract etc. here

For those who can't make it, I will make the slides available online after the conference.

Hope to see you there...

One of the new features in the AspectWerkz 2 architecture is that it comes with a full-blown interception framework that allows per instance programmatic deployment with most of the AOP semantics preserved. You can make use of this using both the regular load-time weaving or the AW Proxy (that I blogged about here)

In short you will get:
Per instance programmatic deployment for before, around, after, after finally and after throwing advice types for call, execution, set and get pointcuts as well as the expressiveness of the AspectWerkz' pointcut pattern language all wrapped up in a very simple and intuitive API.

    POJO pojo = new POJO();

    // adds tracing to all methods in the 'pojo' instance
    ((Advisable) pojo).aw$addAdvice(
        "* *.*(..)",
        new BeforeAdvice() {
            public Object invoke(JoinPoint jp) {
                System.out.println("Entering: " + jp.getSignature().toString());
            }
        }
    );

The Advisable interface

From a users perspective pretty much all you need to know about is in the Advisable interface. This interface is added to all the classes that you want to do per instance runtime deployment at. This interface is added to your classes by the framework, but more on that later.

The Advisable interface basically has two methods that are of interest to you:

• void aw$addAdvice(String memberPattern, Advice advice) - this methods allows you to add an Advice instance to the members specified by the memberPattern argument
• void aw$removeAdvice(String memberPattern, Class adviceClass) - this methods allows you to remove the last advice (that was added last) of the type specified in the adviceClass argument from from the list of aspects applied to the members specified by the memberPattern argument

The different Advice interfaces

The intercept framework supports all main types of advice defined in AOP today:

• AroundAdvice - works like a regular interceptor and is invoked "around" or "instead-of" the target method invocation or field access/modification.
  It has one method you need to implement which has the following signature:
  Object invoke(JoinPoint jp)


• BeforeAdvice - is invoked before the actual member invocation
  It has one method you need to implement which has the following signature:
  Object invoke(JoinPoint jp)


• AfterAdvice - is invoked after the actual member invocation, is invoked both if the method returns normally or with an exception. E.g. can be seen as being invoked in the finally block.
  jt has one method you need to implement which has the following signature:
  Object invoke(JoinPoint jp)


• AfterReturning - is invoked after the actual method has returned normally
  It has one method you need to implement which has the following signature:
  Object invoke(JoinPoint jp, Object returnValue)


• AfterThrowingAdvice - is invoked after the actual method has returned with an exception
  It has one method you need to implement which has the following signature:
  Object invoke(JoinPoint jp, Throwable exception)

Preparing your application

To make this work you finally need to tell AspectWerkz which classes you want to make "advisable" and to which extent. This is done in the META-INF/aop.xml deployment descriptor in which you have to make use of the <advisable .../> element. This element has two attributes:

• expresssion - here you specify the type pattern that picks out the classes that you want to make "advisable" and this is done by defining a within(<TYPE PATTERN>) pointcut expression
• pointcut-type - here you defined which pointcut semantics you want the added advice to follow
  Valid types are:
  • call - the advice added to a method will be invoked on the caller side of the method invocation (if you think client-server then it is executing on the client side)
  • execution - the advice added to a method will be invoked on the execution side of the method invocation
  • set - the advice added to a field will be invoked when a field is modified
  • get - the advice added to a field will be invoked when a field is accessed
  • all - a combination of all the above pointcut types
  Or any combination of these separated by a | character.

Example:

    <aspectwerkz>
        <system id="intercept-sample">
            <advisable expression="within(my.application.domain.*)" pointcut-type="call|set|get"/>
        </system>
    </aspectwerkz>

Bringing it all together

So now we have talked about the Advisable interface that we can use to add the advice we want to a specific instance. We have talked about the different Advice interfaces and their differences. Finally we talked about how we tell the AspectWerkz container which classes it should make "advisable" and how it should treat them. Let's now try to bring it all together in a small example.

In this example we are taking a regular POJO and we are adding an advice that will be applied to all methods that are annotated with the annotation @OneWay and turn the otherwise synchronous invocations into ansynchronous invocations.

    ...

    POJO pojo = new POJO();

    ((Advisable) pojo).aw$addAdvice(
        "@OneWay * *.*(..)",
        new AroundAdvice() {
            private Executor m_threadPool = Executors.newCachedThreadPool();

            public Object invoke(JoinPoint jp) throws Throwable {
                m_threadPool.execute(
                    new Runnable() {
                        public void run() {
                            try {
                                // proceed with the invocation in a new thread
                                jp.proceed();
                            } catch (Throwable e) {
                                throw new RuntimeException(e);
                            }
                        }
                    }
                );
                return null;
            }
        }
    );

    ...

    <aspectwerkz>
        <system id="intercept-sample">
            <advisable expression="within(sample.intercept.POJO)" pointcut-type="call"/>
        </system>
    </aspectwerkz>

Resources

I have not written any specific sample application for this article but if you want you can look at and run the tests in the AspectWerkz distribution. You can download the distribution here. The tests are in ./src/test/test/intercept/* directory and you can run them (along with all the other tests) by invoking ant test when standing in the AspectWerkz distribution's root dir.

One of the new features in the AspectWerkz 2 architecture is the ability to deploy and undeploy aspects at runtime, e.g. to do "hot" deployment and undeployment.

The implementation is based on HotSwap class redefinition and handles 'change sets' which ensures that the changes to each single join point is atomic. What this means in practice is that if you for example are deploying an aspect which has one before and one after advice, both advising the same join point (method/field etc.) then either both of them will be added or none.

The API exposed to the user is very simple and straight forward to use. Everything is handled by the Deployer class, which provides the following API for runtime deployment and undeployment of aspects:

    DeploymentHandle deploy(Class aspect)
    DeploymentHandle deploy(Class aspect, ClassLoader deployLoader)
    DeploymentHandle deploy(Class aspect, DeploymentScope scope)
    DeploymentHandle deploy(Class aspect, DeploymentScope scope, ClassLoader deployLoader)
    DeploymentHandle deploy(Class aspect, String xmlDef)
    DeploymentHandle deploy(Class aspect, String xmlDef, ClassLoader deployLoader)
    DeploymentHandle deploy(Class aspect, String xmlDef, DeploymentScope scope)
    DeploymentHandle deploy(Class aspect, String xmlDef, DeploymentScope scope, ClassLoader deployLoader)
    void undeploy(Class aspect)
    void undeploy(Class aspect, ClassLoader loader)
    void undeploy(DeploymentHandle deploymentHandle)

• in the context classloader (just specify the aspect class)
• in an arbitrary class loader (this option is most useful for application server vendors that can garantuee that all the dependecies can be resolved)
• within a specific DeploymentScope (more about this in a minute)

You also deploy a class without any annotation definition and pass in the definition in XML format. Here you pass in a string containing the <aspect>...</aspect> part of the regular aop.xml definition (see the online docs for details).

Use-case: Implementing a JMX monitoring aspect

Now let's take a look at a concrete example on how to hot deploy an aspect that can do some monitoring for us, report that to an JMX MBean and then undeploy it when the monitoring is done.

Writing the aspect

So first, here is the (main parts of the) JMX monitoring aspect:

    @Aspect
    public class ResponseTimeAspect {

        ... // methods for registering the MBean lazily, member fields etc.

        // the "invocationsToMonitor" pointcut will be defined at deployment time 
        // in the aop.xml file
        @Around("invocationsToMonitor")
        public Object monitor(StaticJoinPoint jp) throws Throwable {
            Signature signature = jp.getSignature();
            long tsStart = System.currentTimeMillis();
            Object result = null;
            try {
                result = jp.proceed();
            } finally {
                // note: this code is using a JMX helper method and  
                // we will have one MBean per jointpoint signature (i.e. method, field, etc.) 
                long tsElapsed = System.currentTimeMillis() - tsStart;
                ObjectInstance mbeanI = registerMBean(signature);
                if (mbeanI != null) {
                    m_mbeanServer.invoke(
                        mbeanI.getObjectName(),
                        "update",
                        new Object[]{new Long(tsElapsed)},
                        new String[]{long.class.getName()}
                    );
                }
            }
            return result;
        }

        public static void enableMonitoring(String pointcut) { ... }

        public static void disableMonitoring() { ... }
    }

Hot deploy and undeploy the aspect

As you can see we have added two static methods to the aspect, these will be used to enable and disable the response time aspect. E.g. deploy it and undeploy it.

First we have the enableMonitoring method, which enables monitoring in our application, e.g. deploys the monitoring aspect. This method can be invoked at any point in time, all threading issues etc. are handled by the underlying implementation. Here we make use of the XML definition to resolve the annotation definition in the aspects by defining the "abstract pointcut" that we have bound the advice to (the invocationsToMonitor pointcut).

    public static void enableMonitoring(String pointcut) {
        String xmlDef = "<aspect><pointcut name='invocationsToMonitor' expression='" + pointcut + "'/></aspect>";
        Deployer.deploy(ResponseTimeAspect.class, xmlDef);
    } 

Second we have the disableMonitoring method which disables monitoring for us, e.g. undeploys the aspect from all the join points where it had been defined (see the concept of DeploymentHandle s for a more fine grained undeployment API).

    public static void disableMonitoring() {
        Deployer.undeploy(ResponseTimeAspect.class);
    } 

Use the aspect to monitor JDBC SQL statements

This means that in the user code, all we need to do to enable and disabling this aspect is to invoke these two methods. Here we will monitor the executions of all JDBC statements:

    public static void trackResponseTimeOfSqlQueries() {
        ResponseTimeAspect.enableMonitoring("call(* java.sql.Statement+.execute*(..))");

        ... // wait a while to do a recording  

        ResponseTimeAspect.disableMonitoring();
    }

What this pointcut expression (call(* java.sql.Statement+.execute*(..)) ) actually means is:

• Pick out all method calls (call(..) )
• to alll methods that has a name that starts with execute (execute* )
• that can have any parameter types ((..) ) or return type (* )
• that are in a concrete class that implements the java.sql.Statement interface (java.sql.Statement+ )

Note: we could in this specific use-case benefit from retrieving and storing the parameter value to the execute*(..) methods, since it is the actual SQL query that we are monitoring the execution time of. This could be done really easy but is out of scope for this article.

So now after doing some monitoring you should be able to easily see the data in any JMX console. For example hook in JConsole which you can read more about in this article.

Define a deployment scope

Finally, to get this to work in the general case we need to define a deployment scope which defines the set potential join points that we might want to monitor at runtime.

This construct gives you (as a application developer or vendor) control over which join points are exposed to the hot deployment API i.e. helps to prevent usage of the hot deployment facilities in specific areas of the application.

This can be done either in the META-INF/aop.xml file or using annotations in the aspect class. In this case we want to make the aspect generic so we will define it in the external XML definition:

    <aspectwerkz>
        <system id="monitoring">
            <deployment-scope name="response_time" expression="call(* sample.deployment..*.*(..))"/>
        </system>
    </aspectwerkz>

Here we have defined a deployment scope that picks out all method calls in our sample application, which means that we can safely deploy our ResponseTimeAspect at these points. (We could have added something like AND within(package..*) to the expression if we wanted to narrow down the scope.)

In the code above we have an implicit contract that says that we can not define the aspect to be deployed outside a deployment scope. If we do not define a pointcut that is wider than this it is all fine. But we can now use this deployment scope to ensure that we only deploy the aspect at valid points. To do that we need to retrieve a handle to the scope like this (can be done at any point):

    DeploymentScope scope = SystemDefinition.getDefinitionFor(loader, systemId).getDeploymentScope("response_time");

Now we can use the DeploymentScope handle to make a more explicit deployment (e.g. knowing exactly the points where our aspect will be applied):

    Deployer.deploy(ResponseTimeAspect.class, xmlDef, scope);

Notes on the impact of the deployment scope preparation

The preparation made by the deployment scope construct means in practice that we are simply adding a level of indirection by adding a call to a public static final method that redirects to the target join point (method, field, constructor). This method will be inlined by all modern JVMs.

When we do undeploy of an aspect, if this aspect is the last one that affects the join point, then the class' bytecode will be reverted to the same state it had before any aspect was deployed.

Resources

More info about the JMX ResponseTimeAspect

The code for the monitoring aspect is based on the implementation of the ResponseTimeAspect in the AWare Project. The only difference is that in this example I am defining it using Java5 annotations and I have added the two static methods for doing the deployment and undeployment. You can read more about this aspect here and the source code for it can be found here.

You can also check out the complete AWare project which has some tests for the JMX module. Info about how to check out the sources can be found here.

More info about the Deployer Module

I have not written any specific sample application for this article but if you want you can look at and run the tests for the deployer module in the AspectWerkz distribution. You can download the distribution here. The tests are in ./src/jdk15/test directory and you can run them by invoking ant test:jdk15 when standing in the AspectWerkz distribution's root dir.

The aspectwerkz*.jar jars and the dependency jars are in the ./lib folder in the AspectWerkz distribution.

The idea

After implementing the AW Proxy extension to AspectWerkz I figured, why not hook into the most widely used proxy implementation out there: cglib and let AspectWerkz weave in the aspects that are around just before the proxy is returned to the user.

The solution

So, this is all that this cglib extension does: asks AspectWerkz if it has anything to say about the class that has just been proxied. If so, then let the AspectWerkz weaver do its job, e.g. weave in the aspects that are currently deployed (on the classpath), and when returns the proxy to the user.

If no AspectWerkz aspects are found that has pointcuts that matches the class being proxied then nothing happens.

All that was needed to make this work was to add 30 lines of code to one single cglib class.

How do I use it?

This means that all you need to do to make any cglib based applications, and there are many: Geronimo, dynaop, Spring AOP, Hibernate etc., become "aspectwerkz-aware" is to replace one single class in the cglib.jar jar.

Or.

If you can't or don't want to patch the cglib.jar jar, you can just put the class before the jar on the classpath.

What is the impact on my existing code?

If no AspectWerkz aspects are found that has pointcuts that matches the class being proxied then nothing happens. And if AspectWerkz is not available then the whole process is skipped. So basically, there is nothing to loose, it is pay as you go (or should I rather say: gain as you go ;-) ).

How do I get it?

The single file you need can be found in the AspectWerkz RC2 distribution, which you can find here.

The cglib extension is in the ./src/cglib-ext dir (in the root of the AspectWerkz distribution). So step into this directory and type ant dist and it will compile the class and put it in a jar that is to be found in the ./src/cglib-ext/target . This jar only contains one single class file (which you either put in the cglib.jar jar or make sure that it is before the jar on the classpath).

In the ./src/cglib-ext dir you also have a sample that you can run. This sample is just a sample taken from the cglib distribution, but it has a tracing aspect on the classpath, that is weaved into the proxy. You can run this test by invoking ant samples:trace .

Enjoy.

Summary

Proxies are an important piece in the J2EE puzzle. Since it offers a non-intrusive an more transparent way of weaving in advice/interceptors. However, non of the current proxy implementations utilizes all the rich semantics of AOP (as defined by AspectJ), the expressiveness of a real pointcut pattern language and has the speed of statically compiled code.

AW Proxy is here to try to narrow this gap. It makes use of the rich semantics for AOP in AspectWerkz and is very high-performant due to the use of static compilation (utilizing the AspectWerkz weaver). All wrapped up a very simple and intuitive API.

The need for proxies

The two arguments against load-time weaving that we hear the most are:

• that it is complex -
  which is an argument that I don't understand, since all you need to do is to add one single VM option when starting up the VM


• that the transparency of proxies is hard to beat -
  which is an argument that I can fully agree on

Adding the possibility of using AspectWerkz together with proxies is something that Alex and I have been talking about for a long time but never implemented due to lack of time. Well, this weekend I took the time and it was actually more simple than I thought.

After a couple of hours coding (taking the cglib route with its "class proxy", e.g creating a new class on-the-fly that extends the target class and which methods and constructors delegates to the base class' methods, but with the difference that they don't wrap the arguments but pass them on as they are, which gives a lot better performance), I had a working solution.

Introducing AW Proxy

The benefit with using the AspectWerkz Proxies compared to the regular load time weaving is that there are no VM options. You simply create your proxy and before it is returned to you it is weaved with the aspects that happens to be available on the classpath at that time.

The API is pretty straight forward. All you need is in the

    org.codehaus.aspectwerkz.proxy.Proxy

    // Returns a new proxy for the class specified
    public static Object newInstance(Class clazz);

    // Returns a new proxy for the class specified, instantiates it by invoking the constructor 
    // with the argument list specified
    public static Object newInstance(Class clazz, Class[] argumentTypes, Object[] argumentValues);

    // Same as above, but with optional parameters for caching and making the proxy advisable 
    public static Object newInstance(Class clazz, boolean useCache, boolean makeAdvisable);

    // Same as above, but with optional parameters for caching and making the proxy advisable 
    public static Object newInstance(Class clazz, Class[] argumentTypes, Object[] argumentValues, 
                                     boolean useCache, boolean makeAdvisable);

• The makeAdvisable argument decides if the proxy instance should be advisable, e.g. be prepared for runtime programmatic deployment. More on this later in this article.

• The useCache argument decides if the Proxy should try to reuse an already compiled proxy class for the specific target class.

  If you set this flag to true then a cached class it is returned (if found) e.g. no new proxy class is compiled. This has both benefits and drawbacks. The benefits being that if there is a new aspect that has been deployed that advises a new join point in the target class then these new join points will not be advised (but already advised join points will be redefined).

  However if you set this flag to false then a new proxy class will be compiled for each invocation of the method, which will make the invocation a bit slower but you will get a completely new proxy class that is advised at all matched join points.

How to use the API?

Here is a little example on how to use the Proxy API:

    // creates and instantiates a new proxy for the class Target
    Target target = (Target) Proxy.newInstance(Target.class, false);

That's it!

This target instance have now been advised with all the aspects that have been found on the classpath that matches the members of the Target class.

Utilizing programmatic runtime deployment

As I said before, when you create your proxy it will get automatically weaved with all the matching aspects that are found (on the classpath). This is most of the time what you want and need, but there might be cases when you want to add a specific feature, at runtime, to a specfific instance only. In these cases you need programmatic runtime per instance deployment.

One of the new features in the AspectWerkz 2 architecture is that it comes with a full-blown interception framework that allows per instance programmatic deployment with most of the AOP semantics preserved.

In short you will get:
Per instance programmatic deployment for before, around, after, after finally and after throwing advice types for call, execution, set and get pointcuts as well as the expressiveness of the AspectWerkz' pointcut pattern language all wrapped up in a very simple and intuitive API.

    POJO pojo = new POJO();

    // adds tracing to all methods in the 'pojo' instance
    ((Advisable) pojo).aw$addAdvice(
        "* *.*(..)",
        new BeforeAdvice() {
            public Object invoke(JoinPoint jp) {
                System.out.println("Entering: " + jp.getSignature().toString());
            }
        }
    );

The advice "interceptors" that are supported are:

• AroundAdvice - works like a regular interceptor and is invoked "around" or "instead-of" the target method invocation or field access/modification.
• BeforeAdvice - is invoked before the actual member invocation
• AfterAdvice - is invoked after the actual member invocation, is invoked both if the method returns normally or with an exception. E.g. can be seen as being invoked in the finally block.
• AfterReturning - is invoked after the actual method has returned normally
• AfterThrowingAdvice - is invoked after the actual method has returned with an exception

Now we can combine use this feature together with the AW Proxies. All proxies that are created implements the Advisable interface which makes it really easy and straightforward to use them together:

Example

In this example we create and instantiate a new proxy for the class Target , we set it to become advisable (e.g. it will implement the Advisable interface transparently), and then we add an after returning advice to all methods that returns an instance of java.lang.String .

    Advisable target = (Advisable) Proxy.newInstance(Target.class, true, true);
    target.aw$addAdvice(
        "String *.*(..)",
        new AfterReturningAdvice() {
            public void invoke(JoinPoint jp, Object returnValue) {
                // do some stuff     
            }
        }
    );

Benefits

Plain proxies with rich AOP semantics

The benefits are, besides a less intrusive and more transparent approach, that you can utilize the rich semantics for AOP (well, not all, see below for limitations) that are supported AspectWerkz. Such as, a rich pointcut expression language, before/after/around advice, deployment modules defined by the META-INF/aop.xml file etc.

Very high-performant

You will also get the full performance of the AspectWerkz 2 architecture.

If you are interested details of the benchmark we made (and/or run it yourself) then you can read this paper.

But in short AW Proxy is roughly:

• 25 times faster than Spring AOP for before and after advice
• 8 times faster than Spring AOP for around advice
• 16 times faster than dynaop for before and after advice
• 5 times faster than dynaop for around advice
• 4 times faster than straight cglib for before and after advice
• 1.25 times faster than straight cglib for around advice

Limitations

Since it is a proxy approach it only supports execution pointcuts and can only advise methods and constructors that is non-private and non-final. E.g not call , set , get or handler pointcuts. Advice bound to these pointcut types will simply not affect the class being proxied.

Resources

This new feature will be available in AspectWerkz 2.0 RC2 that will be available soon. Until then you can check out the sources from the CVS and build it yourself (by invoking ant dist ).

There are some samples in the ./src/samples/examples/proxy dir in the distribution. These can be executed by invoking ant samples:proxy from the command line.

Enjoy.

The AspectWerkz 2 architecture has been designed to be an Extensible Aspect Container, which can deploy and run arbitrary aspects. You can read more about the details in this article.

In this article I will show you how you can make use of this container to run Spring AOP aspects more performant plus utilize the annotation-driven AOP in AspectWerkz along with its more expressive pointcut pattern language.

In this article I am using Spring as an example but everything covered here applies to all frameworks that implements the AOP Alliance interfaces (e.g. dynaop, JoyAop, JAC etc.).

Write a regular Spring advice

First we write a regular spring advice that implements authentication:

    public class AuthenticationAdvice implements MethodBeforeAdvice {

        public void before(Method m, Object[] args, Object target) throws Throwable {
            // try to authenticate the user
            // if not authenticated throw a SecurityException  
        }
    } 

Define the advice using Java 5 annotations

In this example we will not define this advice using the slightly verbose Spring config file. But make use of Java 5 annotations. In AspectWerkz you have a set of predefined annotations that we can use, f.e. one for each advice type. The advice we have implemented here is a before advice so we will use the @Before annotation when defining the advice:

    public class AuthenticationAdvice implements MethodBeforeAdvice {

        @Before("authenticationPoints")
        public void before(Method m, Object[] args, Object target) {
            // try to authenticate the user
            // if not authenticated throw a SecurityException  
        }
    } 

We can of course choose to not define the pointcut in an external XML file but directly in the Before annotation like this:

    @Before("call(@RestrictedOperation * *.*(..))")
    public void before(Method m, Object[] args, Object target) {
        ... 
    }

Define the pointcut in the external aop.xml file

Now all we need to do put this advice to work is to write the little META-INF/aop.xml file. In this case there are two things that we need to define there:

• we need to tell the AspectWerkz container that it should deploy this Spring advice as a regular AspectWerkz aspect
• we need to resolve the definition by defining the "authenticationPoints" pointcut

    <aspectwerkz>
        <system id="spring-extension-sample">
            <aspect class="my.application.aspects.AuthenticationAdvice">
                <pointcut name="authenticationPoints" expression="call(@RestrictedOperation * *.*(..))" />
            </aspect>
        </system>
    </aspectwerkz>

Note that we are using a call pointcut here, which means that this advice will execute on the client side and not the server (something that is not possible with regular spring aop which only supports execution pointcuts). This can be beneficial in many situations, it can f.e. can save us a remove call from the client to the server, or take some load off the server if the client is executing in a separate VM, etc.

Start up the application

The last thing we need to do is to add two VM options:

• we need to register the Aspect Model implementation for the Spring extension in the AspectWerkz container. This is done like this:
  -Daspectwerkz.extension.aspectmodels=org.codehaus.aspectwerkz.transform.spring.SpringAspectModel
• we need to register the AspectWerkz weaver agent:
  -javaagent:lib/aspectwerkz-jdk5-RC2.jar

The you can start up the application as usual using java ... .

We have been thinking of providing a way of defining the spring aspect model on the application level (per META-INF/aop.xml file) and not only on the VM level (using a VM option). If there is interest in this, please get back to us and we will add support for this.

What about my Spring bean config file, dependency injection etc?

Good news is that you can still use your regular Spring bean config file and let Spring do its job, with dependency injection, bean configurations etc.

AspectWerkz has a pluggable factory mechanism for the aspect instantiation and life-cycle management. We have written a factory for the Spring framework that allows you to use Spring to configure your aspects/advice just as usual. Read more about that here.

Much better performance

Apart from allowing defining your aspects using Java5 annotations and using the semantics of the AspectWerkz pointcut language and weaver, you will also get much better performance (ranging between 1300 to 50 percent). I won't go into detail on that here but you can read more about it in this article.

Drawbacks

Everything has tradoffs and there are of course some drawbacks in using the AspectWerkz Extensible Aspect Container as the runtime environment for your Spring aspects/advice:

• You will weave the actual target classes - this is a more intrusive way of doing the weaving, which in some cases perhaps is not beneficial
• You need a couple of extra VM options when you start up your application.
• You need one extra XML (very tiny) config file - the META-INF/aop.xml file

Resources

I have not written any specific sample application for this article but if you want you can look at and run the tests in the AspectWerkz distribution. You can download the distribution here. The tests are in ./src/compiler-extensions/spring/src/test directory and you can run them by invoking ant test when standing in the ./src/compiler-extensions/spring directory. However these tests does not use the Java5 annotation syntax but only the XML definition to define the aspects. But you should be able to modify the tests as you like.

The aspectwerkz*.jar jars and the dependency jars are in the ./lib folder in the AspectWerkz distribution, but the aw-ext-*.jar jars you need to build yourself. This is done by stepping into the ./src/compiler-extensions/spring directory and type ant dist then the jar will be put into the ./src/compiler-extensions/spring/lib directory, use same procedure to build the AOP Alliance extension jar.

I gave an interview for the spanish Java community site javaHispano.org.

Here is the english version.

The Spring Framework is a very powerful library for J2EE development. It comes with an AOP implementation (based on proxies) that is in many cases sufficient in terms of what you need to do. However, there are many situations where you need a more full-blown AOP framework (such as AspectWerkz) to do the job.

On the other hand AspectWerkz (even though it has a decent API for configuration and management) could sometimes benefit from more finegrained and expressive configuration and life-cycle management, which is one thing that Spring does very well.

In short, it is sometimes beneficial to use these two frameworks together and I will now show you a first step on how you can make that happen.

AspectWerkz has a very open architecture in regards to instantiation, configuration and management of the aspects. Here I will show you how you can make use of this to take control over your aspects using Spring. (The concepts are the same for PicoContainer , HiveMind or a home-grown IoC implementation.)

In AspectWerkz instantiation, management and configuration of aspects is handled by an "aspect container" and to make it easier for users to provide their own custom implementation it provides the abstract org.codehaus.aspectwerkz.aspect.AbstractAspectContainer class which handles all the nitty-gritty details.

All we have to do is to extend the org.codehaus.aspectwerkz.aspect.AbstractAspectContainer class and implement the abstract Object createAspect() method.

So let us do that. Here is the implementation of our SpringAspectContainer :

 
public class SpringAspectContainer extends AbstractAspectContainer {

    public static final String SPRING_ASPECT_CONTAINER_CONFIG = "spring-bean-config.xml";

    /**
     * The Spring bean factory.
     */
    private XmlBeanFactory m_factory = null;

    /**
     * Creates a new aspect container strategy that uses the Spring framework to manage aspect instantiation and
     * configuaration.
     *
     * @param crossCuttingInfo the cross-cutting info
     */
    public SpringAspectContainer(final CrossCuttingInfo crossCuttingInfo) {
        super(crossCuttingInfo);
    }

    /**
     * Creates a new aspect instance.
     *
     * @return the new aspect instance
     */
    protected Object createAspect() {
        if (m_factory == null) {
            InputStream is = null;
            try {
                is = ClassLoader.getSystemResourceAsStream(SPRING_ASPECT_CONTAINER_CONFIG);
                m_factory = new XmlBeanFactory(is);
            } finally {
                try {
                    is.close();
                } catch (Throwable e) {
                    throw new WrappedRuntimeException(e);
                }
            }
        }

        // here we are letting Spring instantiate the aspect based on its name 
        // (the m_infoPrototype field is the CrossCuttingInfo instance passed to the base class) 
        return m_factory.getBean(m_infoPrototype.getAspectDefinition().getName());
    }
}

This is all that is needed implementation wise. Now we only have to define which aspects should be managed by our new container and configure the aspect in the Spring bean config file.

To tell the AspectWerkz system that we want to deploy a specific aspect in our custom aspect container we have to specify that in the regular aop.xml file like this:

 
<aspect class="some.package.MyAspect" container="some.other.package.SpringAspectContainer">
    ...
</aspect>

For details on the aop.xml file (what it is, how it is used etc.) see the online documentation.

To configure the aspect we just configure it like any other Spring bean class:

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

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
    <bean id="some.package.MyAspect"
          class="some.package.MyAspect"
          singleton="false"
          init-method="intialize">
        <property name="someProperty">
            ...
        </property>
        ...
    </bean>
    ...
</beans>

For details on how to define your bean classes see the Spring documentation. But here are some explainations:

• id - specifies the name of the aspect if a custom name is define you that else use the class name of the aspect (which is the default name). Mandatory.
• class - specifies the class name of the aspect. Mandatory.
• singleton - specifies if the aspect will be instantiated using the prototype pattern or not. Mandatory.
• init-method - the init-method is the method that you are using to initialize the aspect. This method will be called when all the properties have been set. Optional.
• property - the metadata that you want to pass to the aspect (see the Spring documentation for details on how how to define properties). Optional.

Spring has great support for passing in expressive metadata. It for example allows you to pass in lists, maps of for example strings, primitives or custom objects, and arrange them pretty much as you like.

Here is a more interesting example on how you can configure an aspect using Spring's properties. This aspect implements role-based security and is part of the AWare aspect library:

 
<bean id="org.codehaus.aware.security.RoleBasedAccessProtocol"
    class="org.codehaus.aware.security.RoleBasedAccessProtocol"
    singleton="false"
    init-method="intialize">

    <property name="type">
        <value>JAAS</value>
    </property>

    <property name="roles">
        <list>
            <value>admin</value>
            <value>jboner</value>
        </list>
    </property>

    <property name="permissions">
        <list>
            <bean class="org.codehaus.aware.security.Permission">
                <property name="role">
                    <value>jboner</value>
                </property>
                <property name="className">
                    <value>org.codehaus.aware.security.SecurityHandlingTest</value>
                </property>
                <property name="methodName">
                    <value>authorizeMe1</value>
                </property>
            </bean>

           <bean class="org.codehaus.aware.security.Permission">
                <property name="role">
                    <value>jboner</value>
                </property>
                <property name="className">
                    <value>org.codehaus.aware.security.SecurityHandlingTest</value>
                </property>
                <property name="methodName">
                    <value>authorizeMe2</value>
                </property>
            </bean>
        </list>
    </property>

</bean>
 

You can find the code for the SpringAspectContainer along with many other reusable aspects in the AWare library. Which is a community-driven OSS library for reusable aspects for AspectWerkz.

Yesterday evening I put together a series of two introductory tutorials on AspectWerkz (a third is on its way).

Tutorial one: Hello World.

Tutorial two: Hijacking Hello World

I hope that these will help you to get started with AspectWerkz.

Enjoy.

Just got back from the AOSD 2004 conference. Great experience. Had fun, attended many great talks, met a lot of interesting people etc.

Here are the links to the talks that I/we gave:

• Invited Talk -
  What are the key issues for commercial AOP use - how does AspectWerkz address them?
• AspectWerkz Tutorial -
  AspectWerkz for Dynamic Aspect-Oriented Programming

Today we released the 0.10 Release Candidate 1 of AspectWerkz. Which forms the foundation for the next generation of AspectWerkz.

AspectWerkz has gone through a lot of changes, the whole core engine has for example been thrown out and replaced by a much more flexible and performant one. The join point model is much more expressive and orthogonal we have also implemented a JIT compiler that is making AspectWerkz much more performant. On top of that we have a new implementation of true runtime weaving, which allows you to redefine your aspect model including adding new pointcuts at runtime.

Read more about it here.

The AspectWerkz project is since a a month ago sponsored by BEA Systems. Both Alexandre and I, the founders and primary contributors to AspectWerkz, are full time BEA employees. I work with the JRockit engineering team in Stockholm, and our primary objective is to make AspectWerkz the leading AOP framework for dynamic AOP, and to ensure that the JRockit JVM is far and away the best Java platform for AOP.

We are, of course, working on a number of interesting future directions tight to the in tight coordination with the rest of the BEA products line, but the near term goals are to build deep and unprecedented support for AOP, including real-time run-time weaving into JRockit Java Virtual Machine, and to make AspectWerkz on top of JRockit the number one choice for dynamic AOP in enterprise application environments.

AspectWerkz still is and will remain open source software, licensed under LGPL and will continue being platform and vendor independent.

I was lucky and our submission to JavaOne was accepted.

This means that Alex and I will do a presentation on "Dynamic Aspect-Oriented Programming in J2EE environments".

See you there.

Alex and I will do a half-day tutorial on AspectWerkz at AOSD 2004.

The tutorial will be an introduction to AOP/AOSD and AspectWerkz and to how it can be used in real-world enterprise applications.

It will include hands-on exercises and we will show you how to implement services like:

• Role-based security
• Declarative transaction demarcation
• Transparent persistence
• Asynchronous method invocations
• Caching
• etc.

You can read more about the tutorial here.

We are looking forward to an interesting conference.

Hope to see you there.

Since the last example of the new 'self-defined aspects' model in AspectWerkz seemed to have caused a lot of confusion and made people miss the point, I will in this post try to give a more detailed explaination of the previous 'Role-Based Security' example.

First I just want to stress that this new model of defining the aspects will NOT in any sense make the old pure XML based and the doclet based approaches obsolete. We are here simply providing a new option. A ticket out of deployment descriptor hell.

I also would like to mention that this new model is completely user-demand driven. It solely exists due to the fact that there is a high need for it. It basically solves three problems that the users have been complaining about:

• Separation of implementation and definition. The implementation and the definition are defined in one single file (in the same bytecode). The aspect definition is thus not separated from the aspect implementation
• All advices and introductions needed to implement a concern can be implemented in one single class. The problem with the old approach was that you f.e. for a regular Aspect with two advices and an introduction needed four files. One for each advice and introductions as well as one for the definition. This felt like EJB all over again and the new model addresses this problem in a neat way allowing you to implement everything that is needed in one single class.
• Not pure Java. Even though XML is widely used in the J2EE community and intuitive to most users, it is not Java. It suffers from problems with refactoring, maintainance, reusability etc. This new model tries to address this as well. Even thought the current implementation, based on JavaDoc tags, is not pure Java, it is closer to it and it will be pure Java when we have Java 1.5. Which is what this new model is targetting.

So lets get back to the 'Role-Based Security' example of ours.

The first thing we do is to implement an abstract aspect that contains all implementation for this concern (the advices). But we leave the definition of the pointcuts (where to apply the advices) for later:

    /**
     * @Aspect perThread
     */
    public abstract class AbstractRoleBasedAccessController extends Aspect {
 
         protected Subject m_subject = null;
 
         protected final SecurityManager m_securityManager = ...
 
         /** To be defined by the concrete aspect. */
         Pointcut authenticationPoints;
 
         /** To be defined by the concrete aspect. *
         Pointcut authorizationPoints;
 
         /** 
          * @Around authenticationPoints 
          */
         public Object authenticateUser(JoinPoint joinPoint) throws Throwable {
              if (m_subject == null) {
                  // no subject => authentication required
                  Context ctx = ... // get the principals and credentials
                  m_subject = m_securityManager.authenticate(ctx); // throws an exception if not authenticated
               }
              Object result = Subject.doAsPrivileged(
                 m_subject, new PrivilegedExceptionAction() {
                     public Object run() throws Exception {
                         return joinPoint.proceed();
                      };
                  }, null
              );
              return result;
          }
 
         /** 
          * @Around authorizationPoints 
          */
         public Object authorizeUser(JoinPoint joinPoint) throws Throwable {
             MethodJoinPoint jp = (MethodJoinPoint)joinPoint;
  
             if (m_securityManager.checkPermission(
                m_subject, 
                jp.getTargetClass(), 
                jp.getMethod())) {
   
                 // user is authorized => proceed
                 return joinPoint.proceed();
              }
             else {
                 throw new SecurityException(...);
              }
          }
     }

This aspect is now completely generic and reusable.

Now we can compile this aspect and package it in a library along with the implementation for the security manager etc. The aspect needs to be compiled with a custom compiler which retrieves the attributes and puts them in into the bytecode of the aspect class. This step will not be needed when we are running java 1.5 which has build in support for metadata annontations.

If we now want to use this security aspect of ours we can inherit the abstract aspect using regular class inheritance and define the pointcuts in the concrete subclass:

    /**
     * @Aspect perThread
     */
    public class RoleBasedAccessController extends AbstractRoleBasedAccessController {
 
        /**
         * @Execution * *..facade.*.*(..)
         */
        Pointcut authenticationPoints;
 
        /**
         * @Execution * *..service.*.*(..)
         */
        Pointcut authorizationPoints;
     }

The system needs to know which aspects we want to use and for this we need to write a TINY XML definition file. Here we only need to specify the names of the aspects and NO definition metadata:

    <aspectwerkz>
        <system id="security-test">
            <package name="example">
                <use-aspect class="RoleBasedAccessController">
                    <param name="type" value="JAAS">
                </use-aspect>
            </package>
        </system>
    </aspectwerkz>

Here we can see that I have the possibility of parameterizing the aspect. This can be very useful in some situations since it allows you to use the same aspect with different configurations in different contexts

If you think that inheritance adds too much coupling then you have the option of skipping the concrete subclass completely and define the pointcuts in the XML definition instead:

    <aspectwerkz>
        <system id="security-test">
            <package name="example">
                <use-aspect class="AbstractRoleBasedAccessController">
                    <pointcut-def name="authenticationPoints" type="execution" pattern="* *..facade.*.*(..)"/>
                    <pointcut-def name="authorizationPoints" type="execution" pattern="* *..service.*.*(..)"/>
                </use-aspect>
            </package>
        </system>
    </aspectwerkz>

If you want to play with this new release (which is a release candidate) you can download it here.

On Wednesday (December 3d) I will give a presentation on dynamic Aspect-Oriented Programming in J2EE environments using AspectWerkz at JavaPolis/BeJUG 2003

The presentation will aim at give an understanding on how AOP and AspectWerkz can be used in real-world enterprise applications and will include a couple of hands-on examples.

If you are in Antwerpen, stop by and say hi.

The upcoming release of AspectWerkz (0.9) will have support for a new definition model in which the aspects are self-defined. This means that implementation and definition is written in the same self-contained component.

In this new definition model the aspects are regular Java classes and the advices and introductions are regular methods and inner classes in these classes. The aspects can be abstract and inheritance is used and treated like regular Java class inheritance. The meta-data (aspect definition) is defined using runtime attributes and is currently compiled in into the class on bytecode level (not needed in Java 1.5.x and above).

This new approach makes it easy to create reusable self-contained aspect components and libraries. It simplifies both the implementation, maintainance and refactorings since everything is written in one single Java class.

This is an example of a testing aspect defining a virtual mock object mixin that will be introduced (along with its interfaces) on all the classes matching the pattern foo.baz.*.

/**
 * @Aspect perInstance
 */
public class MockObjectAspect extends Aspect {
 
     /**
      * @Introduce foo.baz.*
      */
     class MockObject extends MyBase implements Traceable, Metered {
          // implementation of the mock object
      }
}

Here is another example showing a skeleton for an aspect implementing authentication and authorization.

/**
 * @Aspect perThread
 */
public class RoleBasedAccess extends Aspect {
 
      private Subject m_subject;
 
     /**
      * @Call * *..facade.*.*(..)
      */
     Pointcut facadeMethods;
 
     /**
      * @Execution * *..service.*.*(..)
      */
     Pointcut needsAuthorization;
    
     /**
      * @Before facadeMethods
      */
     public void authenticateUser(JoinPoint joinPoint) throws Throwable {
          Context context = ... // get principals and credentials
          boolean granted = SecurityManager.authenticateUser(context) // authenticate the user (f.e. using JAAS)
          if (granted) {
               m_subject = ... // set the subject 
           }
          else {
               throw new SecurityException("user not authenticated: " + context);
           }
      }
 
     /**
      * @Around needsAuthorization
      */
     public Object authorizeUser(JoinPoint joinPoint) throws Throwable {
          MethodJoinPoint jp = (MethodJoinPoint)joinPoint;
  	boolean granted = SecurityManager.checkPermission(m_subject, jp.getTargetClass(), jp.getMethod());
          if (granted) {
               // proceed with normal method invocation
               return joinPoint.proceed();
           }
          else {
               throw new SecurityException("access denied at " + jp.getTargetClass() + "." + jp.getMethodName());
           }
      }
}

Currently the runtime attributes implementation is based on JavaDoc tags. These are parsed and inserted into the class on bytecode level, so no source files are needed once the classes have been compiled. This is something that will become obsolete when Java 1.5 and the JSR-175 is released, which will bring runtime attributes to the Java language. The extra compilation step needed to annotate the class files will then not be needed. This also means that pure Java refactorings of both implementation and definition in the aspects will be made possible (e.g. tool support).

The new release is scheduled to be released in the middle of end of november.

Stay tuned.