Wednesday, December 22, 2004

YAPB AOP released

(imported from, read comments there)

I am pleased to announce the first release of YAPB AOP.

For those who don't like this April Fool like YAPB AOP, please read this post on The Server Side - read
Note: YAPBAOP is a real project with real source code and runnable demo !

YAPB AOP is Yet Another Proxy Based AOP for Java.
It is
- proxy-based (AspectWerkz proxy)
- pure java, no language extensions, no external tools needed
- simple and intuitive
- direct, programmatic configuration and un-configuration
- j2ee friendly, no need to mess with class loading
- supports AOP Alliance API for MethodInterception
- JDK 1.5.0 annotations support to match on annotation
- per instance programmatic interception
- full speed

Sample code
here is how YAPB AOP use is simple:

// no aspect
System.out.println(" ( no aspect )");
YapbaopDemo me0 = new YapbaopDemo();

System.out.println(" ( bind a new aspect )");
Yapbaop.Handle handle = Yapbaop.bindAspect(DemoAspect.class, "* yapbaop.demo.YapbaopDemo.*(..)");
YapbaopDemo me1 = (YapbaopDemo) Proxy.newInstance(YapbaopDemo.class);


// get a new one but not using the proxy cache then..
System.out.println(" ( unbind it and get a new proxy YapbaopDemo-2)");
YapbaopDemo me2 = (YapbaopDemo) Proxy.newInstance(YapbaopDemo.class, false, false/*not advisable*/);
me1.method();// still has advice
me2.method();// no advice

Extra features
It was very boring to do and does not bring any value to the table, so please, stop inventing (is is the right word ?) YAPB AOP clones based on your favorite bytecode library / proxy library.

It took 40min to hack (time for a train trip, YAPB AOP are that easy today).

If you want to do something usefull, write an email to your favorite AOP framework representative (AspectJ, AspectWerkz, JBoss AOP, Spring AOP, dynAOP, joyAOP [RIP ?], jeetAOP [RIP ?], YAPB AOP [RIP]) and wonder how to
- write some usefull reusable aspect
- write some good article
- provide a new feature, a performance improvement, a bug report or fix
- go an apply to speak about it to the next conference you can find
- imagine new things !

Download Now !
- Get it there (3 Mo jar since YAPBAOP is actually 1 class of 200 lines messed with a lot of dependancies so that you think it is a killing framework)
- Run the demo with:

java -cp yapbaop- yapbaop.demo.YapbaopDemo

Access the source code
The framework - here
The demo to play with - here
The AOP alliance aspect for the demo - here

Write your own !
Ever wanted to be an Open Source star [*] ? Write your own. Enroll now !
[*] A wrong assumption seems to be that to be an Open Source star, ones have to write at least one YABP AOP. If you only contribute to the next big thing, you ll never be a star, so you 'd better start your own YA RIP framework instead of working with others - that's what mankind is about according to this wrong assumption.

Here are some ideas :
- change the Yapbaop.bindAspect to support binding to a java.lang.reflect.Method
- do the same with an array of java.lang.reflect.Method
- do the same with 1+ Method Annotation(s)
- add some filtering based on 1+ Class Annotation(s)

If you have read till there
Thanks to read this post.
If you dig YAPB AOP architecture, you will find that it is based on
- AspectWerkz proxy
- AspectWerkz extensible AOP container to support AOP Alliance aspect
- AspectWerkz runtime as regards binding of aspects
Quite interesting actuallly isn'it ?

Monday, December 13, 2004

AspectWerkz AOP Eclipse Plugin

(imported from, read comments there)

Well, we for long have said that plain Java AOP and annotation defined aspects don't needs fancy GUI support, but I have to admit, this makes everyones life easier.

So I am pleased to announce the availability of the AspectWerkz Eclipse Plugin based on the 2.x releases.

Get it now, see the doc and the screenshots !

The plugin contains two almost disjunct features:

  • an embedded compiler (a builder in the Eclipse plugin world) for our Java 1.4 strongly typed annotations. Just write the annotations as you would do with Java 5 but in JavaDoc (arrays, nested annotations etc are supported), and write one interface per annotation (where you would write an @interface with Java 5), and the plugin will do the trick when Eclipse will compile your code.
    The annotations are then accessible at runtime (using AspectWerkz Annotations API)and you can use them in your pointcuts (nothing new there).

  • a glue layer that shows the cross cutting view that is add little markers in the gutter to remind you that this piece of code at that line (join point) is advised by this and that before advice in this and that aspect.

(Each feature is a builder so you can deactivate them on a a per project basis if you don't like them / use them.)

Aside since your app will gets weaved, you can just click run and the aspects are in - nothing more to do.
If you need to expose your dependencies jar files to the weaver, use the dedicated AspectWerkz launch configuration that will configure load time weaving for you.

Feedback welcome.
Any volunteer for further evolution ?

The plugin ships for Eclipse 3 and Java 1.4. More to come on Java 5 later.


Oh forgot to say before others make a story about that: yes we are the last one to write an Eclipse plugin, way (decades?) after AspectJ and some month after JBoss.

Wednesday, September 22, 2004

JAOO 2004 AOP coverage - day 1 and 2

(imported from, read comments there)

I am back from the JAOO conference that is happening this week in Aarhus, a city in the west part of the Denmark.
Jonas and I had the opportunity to speak there, and since I feel that there is only a little coverage of it in the blog
community, I have decided to take care of that DK duty.

This post won't give you the right view on this conference, since I attented to my own fields related session aka AOP related, but anyway, you will have a minimum.

The conference

The conference is this year largely sponsored by Microsoft, among others of the .Net or Java ground. Great guys are speaking there, like Rod Johnson (Spring / Interface21 - you know him), Rickard Oberg (former JBoss ejb guy, closed source AOP/CMS lead at Senselogic) , Martin Fowler, Arno Schmidmeier (early AspectJ user, AOSD consultant), Peter Von der Ahé (javac Sun guy), Jonas Bonér and myself to name a few and a bunch of .Net guys.

Though the conference location was a bit far from the airport, the accomodation was good, lunches were fine, with DK stuff but not too much for a FR guy, and the monday night social party was pretty good.

Day 1 - Keynote by Microsoft

I have attended the monday keynote given by a Microsoft guy. It was a good insight to see what MS is attempting to achieve, thinking ahead the C# things while people are just excited about the upcoming release of a new Visual C# things.

it was interesting to hear about how clever is Microsoft when it leads to the latest Java 5 Tiger new features, which are some sort of compiler trick for most of them.
In .Net, when you have an int, this one is an object, and there is boxing / unboxing features somehow, but the int himself is reflectively accessible. In the Java world we have blessed (or cursed as Jonas said...) primitive types (int ...) and boxed types (Integer etc), and Tiger provides boxing and unboxing but thru a compiler trick - that is the bytecode will make use of yourInteger.intValue() and Integer.valueOf(yourint) under the hood.

Microsoft gave a bunch of other samples, and admitted that it was somehow easier to start a good language desgin from scratch that sketching on an existing one.

Day 1 - Sessions

I did not attended more on monday morning since I had to prepare some for our own session and I hope to see someone providing feedback on it since it is not fair to write it myself but still...

Annotation driven AOP with AspectWerkz

Jonas and I were giving a talk in the J2SE track on Annotation and AOP.
We started with an AOP crash course just to get everyone on the train.
Then we explained how Tiger annotations are used in AspectWerkz to have annotation defined aspects (something that JBoss has recently lazily followed).

Annotations are also used in AspectWerkz as a matching mechanism, and we went thru a sample where it is perfectely safe to refactor your methods without taking care about the underlying AOP without any whatever IDE plugings.

You can check our slides there, but for the impatient, here is how our strongly typed matching aspect looks like for annotation driven AOP. As you can see, there is no string based, wildcard based magic there.

// Annotation driven AOP
// Sample of strongly typed matching
// in AspectWerkz AOP with annotations

public class Math {

public Result complexComputation(Arguments args) {
...// this may take a while - we should do it in another thread

public class AsyncAspect {

Object doAsynchronously(JoinPoint joinpoint) {

The session went fine, and the room was pretty much full, with around 400 attendees and after the session we met and chatted some with Rickard Oberg.

After that we had a sort of J2SE panel, which turned out to be a BOF since the JAOO crew had not provided us with a moderator. It ended up in discussing some details and pitfalls in the new Tiger features, like generics and static import.

Night 1 - All conferences are about social events

In the afternoon we met Arno Schmidmeier, an early AspectJ user (meaning late 90's), who is now doing AOSD consulting in Germany (give him a call if you need some AspectJ on-site knowledge), and we then head up to the social event / party with Rod Johnson. Time to share a bunch of beers paid by JAOO sponsors (Microsoft, Borland, Quest, and then I don't really remember) while discussing ideas about Proxy based AOP as in Spring, Geronimo integration, Spring AOP container for AspectWerkz, and some other things.

Day 2 - Sessions

On day 2 I had to leave early and get back at work so I could only make it for Arno and Rickard'sessions and missed Rod' session unfortunately.

AOP - let the code looks like the design

Arno Schmidmeier gave a talk in the Domain Driven Development track, where the main point was to explain how AOP could allow you to let the code looks like the design.

He went thru some use-cases he had seen during his consultancy jobs, and the most interesting part of the session was when he explained how an expression for a domain requirements like "for every successfull bank account operation the accont balance must be checked after the operation and in case of failure, an error should be triggered by the system and the system notified that it should rollabck etc." could be mapped to an AspectJ after returning aspect and thus making his points that AOP enables you to have the code look like the design while avoiding code tangling issues.

Attendees raised questions about code readability, modelling issues and similarities to a predicate language approach. I would have liked to see a running samples in AJDT and alike, and be able to navigate thru the aspects, and may be emphasis more on the domain level pointcuts idea.

Rickard experiences on AOP

I attended Rickard talk about experiences on AOP.
Rickard ellaborated a talk around many of the complex use-case he has for AOP in his company (Senselogic) CMS platform. He started with some classis technical domain concerns, and then jumped on his idea of interface driven system, where an object is actually decomposed in an assembly of entities, each one having a defined stack of advices attached to it.

This approach, which seems quite close to quantum AOP concepts, opens for a bunch of interesting things when it comes to GUI update propagation and server to server replication of sub-graph of persistable objects as well as undo/redo management which again should propagate...

Rickard introduced the idea of a "property=development|production|whatever" pointcut element, that allows for sort of global on/off on the pointcuts. Something you can achieve with a "if" pointcut in AspectJ - although he probably did implemented it at weave time and not at runtime unlike the AspectJ "if".

Rickard then explored the advantages and drawbacks of his "home made" AOP framework, and explained the idea of the abstract schema, where the aspect is abstract and then implements interface of classes where it is actually weaved to, providing sort of natural syntax for accessing the advice target instance methods from within the advice body.

He then went thru a small demo wich showed a nice swinguish things, and then went thru some ajdoc equivalent, where generated javadoc for a class/member is exposing which advices are bounded to it and thru which pointcut.

The next session was Rod Johnson session on Spring and Spring AOP. Unfortunately Jonas and I had to leave since mh, we are pretty busy these days.

Wrap up

Those 2 days were a good investement. I enjoyed the talk we gave there, and it was nice to meet and discuss more with people like Rod, Arno and Rickard.
JAOO has probably a lot more to offer, even if you are on the .net side or on both side (ThoughtWorks had a booth there by the way).
I had some time to think about Rickard abstract schema and experiment some more on Tiger annotations - something I will try to blog about soon.

Get to see the schedule and the JAOO slides there.

Below are some picts of Jonas, Arno, Rickard.

Jonas speaking

Arno session

Rickard explaining his Abstract Schema

Lego guy made in DK

Sunday, September 19, 2004

Annotation-driven AOP in Java at JAOO

(imported from, read comments there)

Jonas and I are going to speak at JAOO about Annotation driven AOP in Java (Tiger / J2SE 5).
The session will cover aspects defined as annotated java classes, as well as matching on annotations and defining strongly typed pointcut thru annotations.

This is a great opportunity to speak there, especially since those ideas have been implemented since the early time of AspectWerkz. Something that some of the other AOP framework are now following.


Thursday, August 19, 2004

Plain Old Java Aspect

(imported from, read comments there)

Back from hollydays, and back to work.

It's time to work on those Plain Old Java Aspects (POJA).
Java 5 Annotations are now so old, in the place since 1.5...

public class Poja {

@Around("execution(* *..*(String message)) AND within(*)")
public Object intercept(JoinPoint jp, String message) {


Tuesday, July 20, 2004

AspectWerkz in WebLogic - domain wizard

(imported from, read comments there)

I have sketeched a BEA WebLogic domain wizard, so that it is now possible to install a WebLogic server with AspectWerkz AOP in a minute.

AspectWerkz AOP WebLogic domain wizard

- WebLogic 8.1 SP2 (8.1 whatever should work).
- Use of JRockit is mandatory for now (included in WebLogic 8.1 or other version if you want).

How to:
- Download the jar (7 Mo, includes the whole AspectWerkz 1.0beta1 distribution with some extra fix).
- Drop the jar file in your BEA_HOME/weblogic81/common/templates/domains.
- Start the BEA Configuration Wizard from the start menu.
- Select the AspectWerkz node and the "WebLogic WorkShop domain".
- Select JRockit
(for other screens, refer to the usual BEA installation documentation)

- It is a WebLogic WorkShop domain wizard. You can probably adapt it for WebLogic Server only, or WebLogic Integration and WebLogic Portal
- Use of JRockit is mandatory, although it is possible with some minimal change to adapt the generated "startWebLogic" script for Sun HotSpot VM (I would do it with the AspectWerkz Plug utility and -Xbootclasspath option - refer to the documentation).
- If you are not using 8.1 SP2, you might need to adapt the "startWebLogic" script to set your JAVA_HOME to the correct JRockit version.

Extra bonus:
- There is draft version of a WebLogic AOP console extension included, that allows you to browse the META-INF/aop.xml definitions accross the class loader hierarchy of your deployed applications.
Just start the weblogic admin console as usual and the extension will appear on the left navigation pane.

Friday, July 9, 2004

AOP in J2EE, Tomcat tutorial

(imported from, read comments there)

Since we released AspectWerkz 1.0 beta 1 some days ago, with a real cool feature we had in our roadmap since the very begining, I have written a small tutorial for you to practice.

AspectWerkz now supports the concept of an AOP container. No other AOP framework out there supports this idea in the way we do it : class loader aware and cross platform.
It is now possible to have an AOP deployment descriptor within your application, and interesting point in an AOP world: have several of them, all along your application.

The standard way of doing so is to use META-INF/aop.xml files, and for some container like Tomcat it is possible to use WEB-INF/aop.xml as well.
If you add a jar file in your application and this jar file contains a META-INF/aop.xml descriptor, it will also be taken into account. It is thus easy to distribute aspect jar file with predefined behavior.

You can drop Aspect classes at your system classpath and those will affect all deployed application, AND, you can have Aspect classes within your web application that will only affect this specific deployed application.

Read the tutorial here.

Note that if an Aspect is deployed within an application, the pointcut it defines will be limited by the class loader isolation principle. Even if the pointcut assumes to match all method in all classes, it will only "see" all methods in classes loaded by this classlaoder and the child classloader.

Try it now !

Sunday, May 30, 2004

Aspect Oriented IT fits BEA Liquid Computing

(imported from, read comments there)

Last week I attended eWorld, mainly as a speaker. It was a unique view on BEA's Liquid Computing vision kick off. Where AOP fits in Liquid Computing vision ? Why should we go on simplifying the AOP stack as our motto in AspectWerkz : full Java, J2EE integration, Java 1.5 readyness, value added Aspects, tool ecosystem... ?

Liquid Computing is the vision for a Simplified Enterprise Computing. Don't think it is SOA. SOA is what BEA provides today with Platform 8.1, but tomorrow, it will be something more.
"The time has come for a comprehensive vision for IT. One that improves business responsiveness by simplifying enterprise computing."
- Alfred S. Chaung
Founder, Chairman & CEO
BEA Systems, Inc.

Reading more in BEA's Liquid Computing pdf brochure, I found it is good exercise to emphasys on specific topics where AOP is a key way to enable Liquid Computing.

Note: the following is my own personnal vision and does not illustrates any official statement from BEA.

Active Adaptability: "Dynamic instrumentation and monitoring will track, display and manage system capabilities. At the core, the infrastructure
is constantly tuning itself in the service of the business."

Self healing policies can be easily builded on Dynamic Aspects.

Dynamic weaving capabilities of BEA JRockit and AspectWerkz has been demonstrated at our eWorld session, activating JMX reporting at runtime, in a web service / pojo based application running on 8.1 and a not yet released version of JRockit.

We can extend the demo to dynamically weave a caching aspect at our web service level to provide a business specific self healing policy. All this stack could be builded in 1 day based on AspectWerkz dynamic AOP stack, no matter the application complexity itself.

This is active adaptabilty now, on Platform 8.1. The same key idea can be enabled today on your older WebLogic Server 6.1, or on your Tomcat stack - whatever is running Java 1.3+ can be handled by AspectWerkz Dynamic AOP.

Enterprise compatibility: "the application just plugs into a
compatibility layer [Compatibility Fabric], rapidly delivering and sharing new

Cross cutting requirements can be addressed rapidly by AOP technologies.

The AOP stack is the compatibility fabric of the cross cutting concerns inherent to all software applications. Thinking AO enables to decouple this concern and address it as a single requirement, allowing change at this level only, to provide the same functionnality with a different underlying implementation but without any change in the application that serves your business.

At our session we have demonstrated an authentication / authorization service implemented in AO. The underlying implementation was using JAAS. It can now be easily enhanced to provide an implementation specific to any IT environment, be it JAAS compatible or not, be it LDAP based, or be it with very specific policies. This software complexity is reduced to the Aspect, and does not impact the functionnal requirements of the application.

It is not WebLogic specific. The same AO stack can be used to secure a Swing based application as well.

The AO implementation brings cross application security live in a minute, no matter the complexity of the application(s) and the IT environment. For more complex requirements, this AO implementation can be enhanced with business specific rules (application flow, business rules, dynamic activation of policies) by adding aspects on the stack, where those are needed.

Breakthrough Productivity: A powerfull engine that extends self-service "into meaningful application functionality. It gives business owners
the ability to make changes to processes and capabilities on their own.[..] There’s no downtime, no need for traditional re-programming and, because IT maintains governance, no loss of IT control."

Self servicing can be enabled thru a dynamic AO stack. Deploy a new aspect that encapsulates a new functionnal requirement, and have it inserted in your running application with dynamic AO, and metadata driven programming.

Metadata driven AOP brings self-servicing to a new IT control era, where model driven architecture can be unleashed by an AO based service stack. Add a cache on service methods, no matter the application was designed for a cache requirements. Change this cache to be distributed, single user based, or for the flow of this specific use-case. Add a JMX reporting layer on it to control cache hit count. Remove this cache when system is not under load.

At our AOP: SOA for the application eWorld session, we have demonstrated hot acitvation of a caching aspect while application was live. We have extended the cache scope to some other business method at a later point, just by using a tool and 3 mouse clicks.

AO solves a traditionnal multi-step IT project iterations in a disruptive way. Pick vendor certified aspects, hotdeploy them with tools and have them bringing your IT to the next generation of your requirements without any downtime. This is Breakthrough Productivity. I would have wrote Disruptive Productivity.

Conclusion: Go live with AO !

The three key concepts of Liquid Computing are part of Aspect Oriented Technologies and especially full java dynamic AOP stacks like AspectWerkz. A good aspect set, tools ecosystem and manageability of the AO layer itself disrupts the classical vision of IT projects. "Design, develop, QA, deploy" is turned into an on demand self servicing layer allowing you to concentrate on your assets. Dynamic AO brings Active Adaptability, address Enterprise Compatibilty and provides Disruptive Productivity.
The AO ways decorrelates your IT complexity from the complexity to address new requirements. Changes are made easy.

I hope this high level view on AO, the issues we aim to address everyday as an AOP stack builder, and the demo we can do today convince you that Aspect Oriented Technology is a key piece of the Liquid Computing puzzle.

Up to us to bring all this value to you now.

Make it live today with AspectWerkz. Ask for docs, demos, support, articles, tutorials. Join us in this aspect and tool ecosystem building.

Go live with AO. Go live with Liquid Computing. Go live with AspectWerkz.

Thursday, May 27, 2004

AOP integration in Tomcat 5

(imported from, read comments there)

On several recent ML post AspectWerkz users complained about getting into troubles when hooking in AOP in Tomcat 5. Steve provided good feedback but ... there is off course a damned better way to handle that !

Here is a little hands on that gives the idea for a 5 minutes shot.
Pretty much straigthforward based on

  • cvs head ie the next 1.0 beta and not 0.10

  • no integration detail, just some bin/aspectwerkz.bat magic

  • aop.xml deployed wihin the target application itself

  • a little fix in a strange file in qdox-1-3.jar

I was concerned about this issue and had an hectic face to face burger discussion with Jonas about "my" so called seamless integration of AOP... I needed to sit down on that and hack, too bad for the jet lag in this crazy GMT 9h far from home SF BEA eWorld clock.

Since the Codehaus had to migrate some CVS details today, the little qdox.jar fix that is needed cannot be commited, but just do it yourself if you want to go on with those explanations. Or wait tomorrow since Bob the despot is around there as well... He'll fix that for me if he is not too busy on the new Codehaus / BEA BeeHive stuff there.

So I took a Tomcat 5 from Apache, unzipped the stuff on my windows box.
I checked that it was fine with the bin/startup.bat and shutted it down to spread AOP in.

Then I made sure that AW *cvs head* was builded, and ASPECTWERKZ_HOME and JAVA_HOME was set.

I decided to give a try to this integration issue and decided to start with a silly tracing aspect that is sitting in AW samples (examples.logging.JavaLoggingAspect). I then builded the samples with a maven target (aspectwerkz:samples:compile)and had a new target/aspectwerkz-samples.jar ready to use.

Then I just opened this bin/catalina.bat that is actually starting things and added this just before the comment:

rem Execute Java with the applicable properties

to have AOP seamless integration:

set CLASSPATH=%CLASSPATH%;%ASPECTWERKZ_HOME%\target\aspectwerkz-samples.jar
set _EXECJAVA=%ASPECTWERKZ_HOME%\bin\aspectwerkz.bat
set JAVA_OPTS=%JAVA_OPTS% -Daspectwerkz.transform.verbose=false

So as you see I go with the bin\aspectwerkz.bat way, which is the easiest kick off stuff we provide, with adaptive behavior regarding Java version detection etc, even if when it comes to production usage I would rather use some JRockit VM.

You will have noticed that I just added my silly tracing sample aspect in the CLASSPATH and replaced bin/java call by bin/aspectwerkz.bat - not taking care about the details.

From there, Tomcat started up *almost* fine. The AW/lib/qdox-1.3.jar has a strange file that Tomcat complains about... Just dropped this from the qdox.jar and we are up and running with AOP online mode / class load time weaving / AOP container from cvs head.

Time to bind my system level tracing Aspect to some application.
I did a try by writting a 5 lines aop.xml file (actually copy pasted it from AW samples/hotdeployed.xml) and dropping it in Tomcat samples in webapps\servlets-examples\META-INF\aop.xml, since this is what we now provided in cvs head (and not in 0.10).

Once that done, nothing happened. I added some tracing stuff (-Daspectwerkz.transform.verbose=true) and figured out (with a bit of pain since toString() on Tomcat classloader is damned too much verbose..) that Tomcat classloader is not taking this META-INF topmost stuff into account.

I decided to move that to the WEB-INF/classes path, so ending up in webapps\servlets-examples\WEB-INF\classes\META-INF\aop.xml [file below]. I ll double check that later since this WEB-INF/.../META-INF is a bit strange there.

and here it is (once I browsed to http://localhost:8080/servlets-examples/)

METHOD_EXECUTION--> filters.ExampleFilter::doFilter
METHOD_EXECUTION--> HelloWorldExample::doGet
METHOD_EXECUTION<-- HelloWorldExample::doGet
METHOD_EXECUTION--> filters.ExampleFilter::toString
METHOD_EXECUTION<-- filters.ExampleFilter::toString
METHOD_EXECUTION<-- filters.ExampleFilter::doFilter
METHOD_EXECUTION--> filters.ExampleFilter::doFilter
METHOD_EXECUTION--> SessionExample::doGet
METHOD_EXECUTION--> listeners.SessionListener::sessionCreated
METHOD_EXECUTION--> listeners.SessionListener::log
METHOD_EXECUTION<-- listeners.SessionListener::log
METHOD_EXECUTION<-- listeners.SessionListener::sessionCreated
METHOD_EXECUTION<-- SessionExample::doGet
METHOD_EXECUTION--> filters.ExampleFilter::toString
METHOD_EXECUTION<-- filters.ExampleFilter::toString
METHOD_EXECUTION<-- filters.ExampleFilter::doFilter


<!DOCTYPE aspectwerkz PUBLIC
<system id="sample">
<aspect class="examples.logging.JavaLoggingAspect">
<pointcut name="pc" expression="execution(* *..*.*(..))"/>
<advice name="logMethod" type="around" bind-to="pc"/>

We are almost there and 1.0 will be damned good don't you think ?

Thursday, May 20, 2004

See you at eWorld

(imported from, read comments there)

I am moving to San Francisco for BEA eWorld.

Jonas and I will give several sessions / demos about AOP in BEA JRockit and the BEA WebLogic Platform, including WebLogic Server and WebLogic WorkShop.

In case you are in the area but do not attend to eWorld, just join the Silicon Valley BEA User Group since we will be there on wedsnesday as well.

We have been under the radar since AOSD, so be ready for something disruptive !
I will post a viewlet of some parts of the demo in some weeks.

Wednesday, February 25, 2004

dynamic AOP and HotSwap

(imported from, read comments there)

In a recent post Bill Burke describes his preliminary research as regards HotSwap usage for dynamic AOP.

He first defines in a few words what is dynamic AOP and what is the HotSwap or class redefinition in Java. Then he briefly describes how JBossAOP handles
dynamic AOP thru a "prepare" phase, and gives some measurements about the overhead he obtained when using the -Xdebug mode during a JBoss startup sequence, an option required to activate the HotSwap API under Java 1.4.

I would like to give some feedback on his post, since I have been working in the dynamic AOP field for some time now thru my involvment in AspectWerkz and
thru a research paper and a runtime weaving prototype I did for the Dynamic Aspect Workshop for AOSD 2004.

I think dynamic AOP has to be splitted in two categories:

  • rearranging AOP constructs at existing join points

  • redefining join points (we could generalize with redefining pointcuts, or even redefining the whole AOP system)

The first category is fully supported by AspectWerkz. It is possible to rearrange (add/remove/reorder) aspects and advices at runtime providing that the join point(s) where the construct(s) is(are) bounded is(are) already existing as a result of the transformation phase, no matter it is a post compilation phase (ala AspectJ) or a class load time weaving.

As regards introductions, AspectWerkz allows to change the introduction implementation (thus the implementation of the added methods) at runtime (swap mixin implementation), again providing that the binding (which mixin(s) applies to which class(es)) is already existing.

This first category relies on the framework capabilities and several means allow to minimize the overhead when f.e. no advice is bounded at a particular join point.

The overhead even if minimal cannot be avoided here. Even reduced to a method call that does a boolean check, this is not the original bytecode instruction sequence which is running when the join point is reached.

This category is the one supported by JBoss as well.

The second category is the most interesting one. Redefining join points (thus pointcuts) allows - in theory - to add new AOP construct at new locations (join points) in the running application.
This should come with the guarantee that there is

  • absolutely no runtime overhead prior the "activation" of the new join points, and no overhead after "deactivation"

  • no assumption that the join points are known before activation (especially at class load time / application deployment time)

I think that this second category requires runtime weaving capabilities from the AOP framework (as long as the AOP frameworks rely on bytecode instrumentation).

A use-case for join point redefinition at runtime is some on-demand profiling tool that needs to activate profiling only when necessary, for a limited time, and without any overhead prior to activation, and without specific knowledge on what will be profiled at application deployment time.

As Bill explains, JBossAOP "addresses" the second category by providing a way to declare pointcuts with nothing bounded. This definition is used at class post compilation / class load time and is what Bill calls the "prepare phase".

The overhead involved by such an approach is not measured by Bill, but is conceptually limited to a boolean check and a method level indirection, this for each pointcuts declared for future activation.

I don't think this approach is really adressing dynamic AOP. The overhead at a single join point level is indeed minimal, but we might have a need to declare very invasive pointcuts to allow further on-demand profiling (or other AOP based constructs), and thus this minimal overhead might occurs trillions times in the running application (potentially at each method call, each method execution and each field access).

So what might be a better solution for true runtime join point redefinition ?

As Bill quotes, HotSwap API allows to change the implementation of method / constructor bodies of a class at runtime, and inject them in the running JVM.

There are some interesting things to consider, that Bill forgot to mention and led him to some approximative statements (I forgot to told him ;-) )

  • HotSwap is an optional JVM capability. Some JVMs do not have HotSwap support (f.e IBM JRE)

  • HotSwap might forbid class schema change. It might not be possible to add new methods (even private ones) to a class when redefining it. This schema change support is itself an optional HotSwap capabilitiy. Currently no JVM supports schema change, but the API does not restricts it.

  • HotSwap exists since Java 1.4, requires -Xdebug mode, and can only be called from a remote JVM (well almost, read below)

  • HotSwap is slightly modified in Java 1.5 and does not requires -Xdebug mode

So considering what HotSwap can do, and what bytecode instrumentation oriented AOP frameworks do to enable AOP in Java OOP, especially to enable dynamic AOP constructs of the first category I described previously, HotSwap seems very attractive, but is currently missing key things.

There might be some ways to address the problems thought...

The fact that the java level HotSwap API as described in Java 1.4 JPDA requires a remote JVM attached to the running JVM (or a JPDA LaunchingConnector) can be avoided by implementing a JNI layer on top of the C-level HotSwap API so that HotSwap is available at Java level, without coupling with the JPDA architecture: no need for a remote JVM, and no need for a LaunchingConnector (that would forbid further remote dedbugging ...).

I describe the advantage of this JNI glue in the work I submitted to the DAW AOSD 2004, and call it "in-process HotSwap". We have it in Java 1.5 so there is no problem on this side anymore.

The "in-process HotSwap" - Java level API - is standardized in Java 1.5 thru the JSR-163. Java 1.5 will not requires -Xdebug to enable the HotSwap API. As you might have understood, the HotSwap API is not that coupled to the JVM debugging capabilities, althought the API was part of the same block in Java 1.4.

The -Xdebug overhead issue raised by Bill is fixed (though I would like to do measurement of what -Xjavaagent in Java 1.5 involves).

The schema change support would be interesting for AOP join point redefinition, since as Bill explains, AOP frameworks that allow dynamic AOP (AspectWerkz, JBossAOP) require some structural changes to bring in enough indirection level between the join point (in the weaved classed) and the AOP constructs (handled by the AOP framework internals).

A simple bytecode decompilation of an AspectWerkz weaved class with execution pointcut will show you that AspectWerkz has added a wrapper method to handle the join point and renamed the original method, since it will be called by the framework as a result of the execution join point construct.

class Foo {

public void doAction() {
// the bytecode for your code


can appeared transformed after the weaving as (approximation)

class Foo {

JoinPointManager __AW_joinPointManager =...

public void doAction() {
__AW_joinPointManager.proceed(this, "doAction()");

private void __AW_doAction() {
// the bytecode for your code

As a consequence, if we would like to be able to redefine (f.e. simply define) the "* Foo.doAction(..)" execution pointcut at runtime, we would need schema change support. The schema change support might not be needed though for caller side constructs.

The problem is thus more a HotSwap API problem, tight to current JVM limited capabilities.

I think that HotSwap - if largely adopted by JVM implementation - can be a good enabler for dynamic AOP as regards pointcut redefinition at runtime. I don't think that the debate is limited to a -Xdebug option, and Java 1.5 demonstrates it.

In the work I submitted to the DAW AOSD 2004, I describe how we are able in an AspectWerkz prototype to redefine pointcuts at runtime even without schema change support.

I agree that this solution (which I will publish later in my blog) is itself not optimal but I was able to demonstrates the feasability of such an on-demand AOP approach, instead of an invasive pointcut definition, that might itself lead to a globally large overhead. I was able to do the prototype with Java 1.4, and it will be even more easy to do with Java 1.5 and the standardized "in-process" Java level HotSwap.

I will debate if HotSwap is good for dynamic AOP at the DAW AOSD workshop, and you bet, some more JVM level AOP support might be crucial on this area.

So far so good, what do we wanted ?

Probably not a low level "addPointcut(<pointcut pattern>, Class klass)" API with a controlled and guaranteed minimal (or even zero) global overhead prior activation, but maybe a more usefull system wide control like "addAOPSystem(ClassLoader klassScope, SystemDefinition definition)" to be able to activate AOP constructs as a whole, at runtime, and leaving the internal recipe of it to AOP solutions and JVM implementations ...

Right ?

Tuesday, February 17, 2004

It's life

(imported from, read comments there)

Most of my blog' fans (do I have blog fans ?) might think I am hacking AOP constructs and weaving architecture all the day.

Well I have to admit that this is not exactly true, thought almost true ;-).

These days I had to hack a small app that gather data from a WebLogic Server farm (more than 60 servers) by querying runtime JMX mbean so that we can then generate some graph to feed a NOC intranet.
Rather simple to play with JMX, have a fault tolerant client that does not crash when one instance is downed, and be able to handle at least 10 Go log daily.

For now the logs are parsed and consolidated as regular file. I would have liked to use a MySQL or HSQL database instead of parsing Go of files... but well, it is a customer driven story.

Here is a pretty cool graph that I got using JFreeChart that shows some http session data history grabbed from a subset of the farm.
Fun ?

Click to enlarge

Tuesday, January 6, 2004

AspectWerkz AOP - new pointcut expression implementation

(imported from, read comments there)

Today I finished my implementation of the new AspectWerkz pointcut expression language.

AspectWerkz had already a good usability level as regards pointcut expression. Most of the needed syntax to bind pointcuts with advice or introduction had been implemented by Jonas, based on an algebra backed by Jexl.

/** @Aspect perJVM */
public class MyAspect extends Aspect {

/** @Execution com.*.Foo.set(..) */
Pointcut pc1;

/** @Execution com.*.Foo.get(..) */
Pointcut pc2;

/** @Around pc1 OR pc2 */
Object advice(Joinpoint jp) { .. }


The previous implementation supported the complete AND / OR / NOT algebra:

pc1 OR pc2
pc1 AND ( pc2 OR pc3 )
pc1 AND NOT pc2

And some synonyms were also provided, like &&, || and !, and other lowercased operators (or, and, not).

What I found bad with this Jexl based implementation was the following:

  • very hard to add new syntax operator (like IN for cflow pointcut composition)

  • added a programmed AST on top of the Jexl AST, but without providing a true Visitor pattern exposure

  • lost boolean expression optimization f.e. needed to evaluate all pointcut in an OR expression like pc1 OR pc2 even if pc1 matched

  • used only a tiny part of Jexl capabilities (Jexl is the evaluation engine of Velocity)

After some digging in Jexl extensibility I decided to start my own boolean expression implementation based on a JJTree grammar. In two days I had the complete operator set I needed, and a true Visitor pattern exposure.

In other two days I was able to refactor Jonas' work to plug my JJTree implementation in AspectWerkz. It allowed to solve a pending issue we had in the 0.9.RC1 release as regards cflow support for model 2 JSR-175 style Aspects.

Now we have many advantages at the hand:

  • no impact for the user

  • faster, especially when boolean optimizations are possible

  • cleaner, with Visitor pattern

  • more usable: with the new cflow composition thru the IN operator

From a user point of view this grammar add a new operator for cflow: the IN and NOT IN (or ! IN etc ...).
It allows to express in a natural way the pointcut expression with cflow.
pc1 OR pc2 IN cflow1
is then different from
( pc1 OR pc2 ) IN cflow1
[ the previous syntax was not natural : pc1 && cflow1 ]

In the next month, I should have time to add the needed glue to support several level of cflow composition - since this is already supported by our JJTree grammar :
pc1 IN ( cflow1 OR ! cflow2 )

This time, the trick will be more at the runtime during the joinpoint evaluation.