Introduction

This article is introducing HyperBeans, a proposal for a framework for Symmetric Aspect-Oriented Software Development in plain Java (i.e. no extensions to Java is being used). These ideas are based on the work I have done in AspectWerkz and in the JVM support for AOP in JRockit and are loosely based on the work on Classpects by Kevin Sullivan and Hridesh Rajan.

If you don't care about the research and background behind the ideas presented in this article (and want to see some code right away), then you should skip the rest of this section.

Aspect-Oriented Software Development (AOSD) in general, tries, among other things, to address the problem defined as the tyranny of dominant decomposition , in which the prominent concerns, usually the business logic, dominate the class design, especially the inheritance hierarchy (as observed in this article).

Historically there has been (and still is) two different main philosophies in AOSD, the asymmetric philosophy and the symmetric philosophy. A detailed discussion about their semantic and philosophical differences is out of the scope for this article (read this article for a detailed discussion).

Juri Memmert has written a good introductory article on the subject in which he defines the different philosophies like this:

The asymmetric philosophy

An asymmetric approach to AOSD relies on the notion that there is a base body of code that is then augmented with aspects. There is a concept ional difference (and an implementation difference) between the base and the aspects so that an aspect can not serve as the base of another composition. Most asymmetric approaches use language extensions to declare aspects as first class entities.

The symmetric philosophy

A symmetric approach to AOSD is based on the notion that all concerns in a system are created equal and, in the asymmetric terminology, can serve as both aspect and base in different compositions. Most symmetric approaches use programming languages as-is, although there are approaches that rely on language extensions as well.

The leading implementation for asymmetric AOSD is AspectJ, while the most well-known symmetric implementation is Hyper/J (now part of the Concern Manipulation Environment (CME) project).

Asymmetric AOSD has so far been the dominant way of implementing AOSD in Java, and in the enterprise space at large. There has been, and still is, a lot of debate in the research community around whether the symmetric or the asymmetric philosophy is the best way of implementing AOSD and many papers have been written on the subject (see the reference section at the end).

When implementing the AspectWerkz AOP framework (which now has been merged with AspectJ), I have been involved in efforts trying to stretch the boundaries of asymmetric AOSD and even though I believe that the asymmetric approach is the preferable in many cases, it definitely has some shortcomings. For example, asymmetric AOSD addresses the problem of 'the tyranny of dominant decomposition' by allowing us to modularize all concerns, but the dominant concern, using aspects. Since the dominant concern needs to serve as "base", the decision deciding which concern should be seen as the dominant one still needs to be taken, and this is a decision that should not be taken lightly since it is something that is usually very hard to change.

When taking a look at how a symmetric approach handles the above given problem, I find the symmetric solution very natural and appealing (at least conceptually). In which, if using Hyper/J's terminology, a system is seen as a multi-dimensional hyperspace, which is built up using different hyperslices (dimensions). A hyperslice is the abstraction of a concern, which can be built up by many components. This gives you the possibility of viewing the hyperspace (your system) differently in regards to different hyperslices (concerns); you have the possibility of looking at the system from the point of view (concern) that you currently want.

I do not want to take any position in regards to if symmetric AOSD is a (or will be a) serious contender to asymmetric AOSD. I simply have not used the symmetric approach to solve real world problems enough yet, but I do believe that it is something worth exploring more. So, let's take a look at the proposal.

HyperBeans – multi-dimensional POJOs

There is no the distinction between classes and aspects, e.g. no need for one concern to serve as "base", all there is is HyperBeans. HyperBeans are regular Plain Old Java Objects (POJOs), they are instantiated with new and you work with them just as with regular classes, no configuration file or similar is needed.

Similarly, there is no the distinction between methods and advice, there are just regular methods, which can be invoked explicitly (like regular methods) or implicitly (when a join point is being executed - like a regular advice).

Deployment and undeployment

HyperBeans are instantiated using the new keyword, which will call the constructor and instantiate the HyperBean just like any other POJO. However, the constructors can also control deployment of the HyperBean.

Deployment of a HyperBean means that its "blessed" methods (advice) are weaved in, while undeployment means that the woven code is removed.

You control deployment of a HyperBean by annotating (one or many of) its constructors with the @Deploy annotation. This example shows how to deploy a HyperBean as a singleton (more on other instantiation models later):

public class POJO {

    @Deploy
    public POJO() {    	
    }

    ... // remaining methods omitted 
}

Since there is no such thing as 'destructors' in Java, we are handling undeployment of HyperBeans by annotating a regular Java method (static or member) with the @Undeploy annotation. This means that when such a method is invoked, the HyperBean will be undeployed. It also give us the possibility of doing additional clean up (closing resources etc.) if necessary:

public class POJO {

    @Undeploy
    public void close() {
        // clean up - close resources etc.
    }

    ... // remaining methods omitted 
}

Instantiation models

You can control instantiation model (also called the deployment scope) of the HyperBean by adding a special argument to the constructor. This special argument defines the deployment scope for the HyperBean and needs to be annotated with the @Scope annotation. What this means is that the HyperBean will be deployed with the scope defined by the type of the argument.

For example, adding the argument @Scope Thread scope to a constructor, (which is annotated with the @Deploy annotation), will deploy the HyperBean with the scope of this particular thread.

Here are all the currently supported instantiation models:

Type annotated with @Scope	Instantiation model
No argument with a @Scope annotation	Singleton
Thread	Per Thread
Class	Per Type
Instance (but not of type Class or Thread)	Per Instance

Here are some examples:

public class POJO {

    /** Singleton deployment */
    @Deploy
    public POJO() {    	
    }

    /** Per Type deployment */
    @Deploy
    public POJO(@Scope Class scope) {    	
    }

    /** Per Instance deployment */
    @Deploy
    public POJO(@Scope SomeType scope) {    	
    }

    /** Per Thread deployment */
    @Deploy
    public POJO(@Scope Thread scope) {    	
    }

    ... // remaining methods omitted 
}

The current semantics for the @Scope annotation is that it:

• Narrows the scope for the matching. For example using the Per Type instantiation model will add an implicit && within(scope) to the pointcuts defined in the HyperBean (same as in AspectJ).
• Controls the life cycle. The HyperBean will have the same life cycle as the instance annotated with the @Scope annotation.
• Controls state management. Tied to the life cycle.

Control flow management - no more cflow

There is no more any need for the cflow pointcut (as defined by AspectJ). Instead we suggest a simple programmatic model for control flow management of HyperBean deployment. I believe that the same functionality can be reached by a combination of the Per Thread instantiation model and the deployment/undeployment API. This approach has similarities with the work done in CaesarJ and its concept of a deploy {..} block. Here is an example:

You have a HyperBean that can be deployed on a per-thread basis:

class POJO {
    @Deploy
    public POJO(@Scope Thread scope) {    	
    }

    @Undeploy
    public void close() {
    }

    ... // remaining methods omitted 
}

Then you can use the following idiom to achieve fine grained control flow (cflow) management:

POJO hyperBean;
try {
    hyperBean = new POJO(Thread.currentThread()); // deploys the HyperBean to the current control flow ONLY
    
    ... // do stuff - the HyperBean is woven into this control flow ONLY

} finally {
    hyperBean.close(); // undeploy the HyperBean from the control flow
}

If you don't want to have this be tangled with your application logic, you can of course put the block in an advice, (and have its HyperBean be a singleton and instantiated somewhere else):

@Around(..)
public Object cflowAdvice(InvocationContext ctx) {
    POJO hyperBean;
    Object result;
    try {
        hyperBean = new POJO(Thread.currentThread()); 
        result = ctx.proceed();
    } finally {
         hyperBean.close(); 
    }
    return result;
}

Cross-cutting methods - advice

So how do we define these "blessed" methods? They are defined using Java 5 annotations, in a similar fashion to AspectWerkz's and AspectJ 5's annotation style of development, but mixed with the API defined by the JVM support for AOP in JRockit (as described in this article ).

Let's take a look at an example:

public class POJO {
 
    @Before("call(Foo.new(..))")
    public void doSomething() {
        ... // do something before an instance of Foo is created
    }

    ... // remaining methods omitted 
}

This is a regular POJO with one "blessed" method that performs some action before an instance of Foo is created. There's really nothing special with this class apart from that one of its method is annotated with a special annotation borrowed from the annotation style syntax in AspectJ. Now let's take a look at a (slightly) more interesting example, one that makes use of contextual information.

public class POJO {
 
    @Before("call(@test.TraceMe * *.*(..))")
    public static void traceBefore(@CalleeMethod Method callee) {
        System.out.println("--> " + callee.toString());
    }
  
    @After("call(@test.TraceMe * *.*(..))")
    public static void traceAfter(@CalleeMethod Method callee) {
        System.out.println("<-- " + callee.toString());
    }

    ... // remaining methods omitted 
}

This is a regular POJO with two different "blessed" methods (that are tracing invocations to all methods that are annotated with the @Trace annotation). Contextual information (like caller and callee method, caller and callee instance, parameters, return value etc.) is retrieved using annotated parameters borrowed from the JRockit API for AOP .

Here is a list of the current set of defined annotations and their meaning:

Annotation	Exposes
@CalleeMethod	The callee method (method, constructor, static initializer)
@CallerMethod	The caller method (method, constructor, static initializer)
@Callee	The callee instance
@Caller	The caller instance
@Arguments	The invocation arguments (wrapped in an object array)
@Returning	The return value (used in 'after returning advice')
@Throwing	The exception thrown from a method (used in 'after throwing advice')

These annotated arguments (except caller and callee method) also works as 'filters', the same is true for all unannotated arguments which are treated as the regular arguments to the method (or the field value about to be set etc.). The methods can be either member or static (dependent on if you want to keep state in the instance or not).

Since some people might be curious how "around advice" (i.e. 'interception') is handled, below is an example of how to implement the same functionality as in the class above using an "around advice". Here we introduce the InvocationContext abstraction (similar to the ProceedingJoinPoint abstraction in AspectJ), which serves as the context on which we can invoke the proceed() method in order to continue with the execution flow.

public class POJO {
 
    @Around("call(@test.TraceMe * *.*(..))")
    public Object trace(InvocationContext ctx, 
                        @CalleeMethod Method callee) {
        System.out.println("--> " + callee.toString());
        Object result = ctx.proceed();
        System.out.println("<-- " + callee.toString());
        return result;
    }

    ... // remaining methods omitted 
}

Implementation

I have prototyped HyperBeans using the JVM support for AOP in JRockit. The implementation was actually very simple and shows the power of the JRockit API (the JRockit prototype is available now for those who wants to try it out).

I am planning on writing another article in which I go through (and release) the actual implementation.

Stay tuned.

My Japan tour is starting to come to an end. During the past week I have been traveling in Japan, done two general sessions at BEA Tech Day 2005 conferences (Tokyo and Osaka), plus a press conference and a bunch of BEA internal training sessions.

I had never been to Japan before, but I am very interested in their culture and I love Japanese food, so this trip has in many ways been a very interesting and fun experience. I had some fears that my visit would turn out similar to the movie 'Lost In Translation' by Bill Murray (for those that have seen this movie), but my fears were unfounded. Most people spoke good english and I only met very generous people with a lot of heart.

Excitement around AOP

There is a lot of excitement and interest around AOP in Japan, both among developers, management and press. They are especially excited about AspectWerkz (it is actually more popular than AspectJ) and JRockit support for AOP.

It was fun to learn that they had translated every single article I have written, to Japanese. On the other hand, the problem having to translate almost every article and book is one of the biggest hurdles on the way to mass adoption of AOP.

Press conference

The press conference I did was an interesting experience, it was my first real press conference, with interviewers lined up, pounding me with questions. It was a lot of fun. The topic for the interview was JRockit and its new AOP support which they seemed very impressed about.

They have already published, two articles based on the press conference:
http://www.atmarkit.co.jp/news/200508/31/bea.html
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050830/167117/
and from what I understand, two more articles with the published.

BEA Tech Day 2005 in Tokyo

The general session I did had around 350 attendees and was simultaneously translated. Things worked out pretty well. People seem to like the talk and came up with a bunch of really good questions at the end. What was even more fun was that there were actually other speakers that talked about AspectWerkz/AspectJ in different contexts. One guy for example, talked about how to implement the transaction and dependency injection parts of the EJB 3 specification using AspectWerkz. In general, one of the main themes of the conference was AOP.

Afterwards, during the conference party, I was treated almost like a celebrity, with "fans" coming up and wanted to shake hands and have a picture taken with the mysterious AOP guru from the north pole (Sweden). :-)

Seasar framework - a Japanese Spring killer?

During lunch at the conference I had the pleasure of having interesting discussion with the founder of the dependency injection and component framework Seasar. For those that have never heard about Seasar, Seasar is a project very similar to Spring, which is more popular than Spring here in Japan. It uses plain bytecode manipulation to do the AOP part (and not proxies), and is based on the AOP Alliance interfaces. One cool thing that I found out about the project is that they are not only using but are very excited about Alex's and my project backport175 (so much that they actually asked to contribute back some code).

BEA Tech Day 2005 in Osaka - Kyoto sightseeing

Today I am off for Osaka for my last talks at the BEA Tech Day 2005 in Osaka tomorrow. The trip will conclude with one day off, which I will spend sightseeing in Kyoto. Kyoto is the historical and cultural center in Japan, with many buildings and temples being more than 1000 years old (compared to Tokyo which is only a couple of hundred years old). So that is going to be interesting.

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.

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?

]]> aop jboner 2005-07-18T12:07:24+01:00 http://blogs.codehaus.org/people/jboner/archives/001106_dso_transparent_clustering_enabled_through_aop.html 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

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.

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.

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...

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.

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 DeploymentHandles 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.

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.

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.

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.

Here is the english version.

]]> aop jboner 2004-11-02T08:28:42+01:00 http://blogs.codehaus.org/people/jboner/archives/000826_spring_and_aspectwerkz_a_happy_marriage.html 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.

]]> aop jboner 2004-08-31T20:01:19+01:00