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