Wednesday, July 13, 2005

Opt-out AOP: good or evil ?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

There is an interesting option in AspectJ that is named -Xreweavable.



When turned on using any kind of compilation/weaving mode (compiling with ajc, within Eclipse AJDT, doing bynary weaving, or using loadtime weaving), each weaved class keeps track of


  • the aspects that are affecting it

  • its state before the weaving happened (ie its bytecode without aspects)





This option is very handy when you plan to weave more than once your application (because f.e. this is a library that you distribute), and when you want to make sure everyone will be able to add some more aspects in there.

Actually, discussions are taking place if this should be the default.



An interesting consequence is that it is fairly easy to implement an opt-out AOP engine that simply restores the state prior to weaving, and thus kicks out all the aspects from the application !

There are of course realistic use-cases for it :


  • sanity check if production is very scared about use of AspectJ, knowing that the developpers team is using it for their own needs (declare error / warning f.e. and tracing in QA stage etc)

  • obtain some more info about which aspect is in, and is affecting the application, to increase the trust everyone gets in using the technology

  • introspect some third parties libraries and see if they actually use aspects

  • add some more reporting features on the go, to be able to have at any time the list of aspects that are in the system f.e. thru some sort of web console

  • enforcing that some key section of the system are not allowed to be advised by anything, or only by some sort of well know and certified aspect(s)





A small amout of code is required for it, the trick is mainly to add another Java 5 agent or loadtime weaver that will check for this reweavable state and do the reporting.

This is actually very easy to do when using f.e. AspectWerkz-core as the backend to hook this one in and have it work as well on Java 1.3, and using ASM for the bytecode details.




Here is a sample output (I am using AspectJ loadtime weaving to do the weaving first, but that could be done using post compilation with AJC, or compilation from within Eclispe AJDT etc)

// in this sample, start the app with AspectJ loadtime weaving (could have been compiled with ajc instead)
// and pipe with the UndoAspectJ opt-out engine using the AspectWerkz core
// as a backend
#java -javaagent:aspectjweaver.jar -Daj5.def=test/aop.xml
-javaagent:aspectwerkz-jdk5-2.0.jar
-Daspectwerkz.classloader.preprocessor=
org.aspectj.ext.undoaspectj.ClassPreProcessor
test.undoaspectj.Sample

weaveinfo Type 'test.undoaspectj.Sample' (Sample.java:28) advised by
around advice from 'test.undoaspectj.Sample$TestAspect' (Sample.java)

// here is the opt-out message
UndoAspectJ - test/undoaspectj/Sample was affected by
test.undoaspectj.Sample$TestAspect

// execution without any aspect takes place:
Sample.target



// without the opt-out we would see the aspect executing:

weaveinfo Type 'test.undoaspectj.Sample' (Sample.java:28) advised by
around advice from 'test.undoaspectj.Sample$TestAspect' (Sample.java)

// execution with aspect takes place:
Sample$TestAspect.around
Sample.target




Though the first idea is quite odd and counter productive, this illustrates that ones could easily implement a security layer on top of AspectJ without even going deep in the AspectJ code base, to enforce security constraints about the use of AOP in the system and in the deployments at large.



So is opt-out AOP good or evil ?

Tuesday, July 5, 2005

@AspectJ in AJDT - a world premiere !

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

I am happy to announce that the @AspectJ support within Eclipse AJDT will appear in the next build snapshots, ie very soon !

That is an important step that brings to the AspectWerkz and AspectJ merger all its meaning, by providing a plain Java syntax (based on annotations) to write AspectJ aspects (aka @AspectJ) while still providing excellent support for it in Eclipse AJDT plugin - just as it exists for the well know AspectJ style (code style).

In the list of things to already expect, that will officially ship as of AspectJ 1.5 M3 in the following days:

  • error checking for pointcuts (even though those looks like strings within an annotation)

  • warnings when @AspectJ annotations are misused (f.e. used in a class that is not annotated with an @Aspect annotation etc)

  • advised by view

  • advises view and cross-reference view

  • and off course AJC integration (ie weaving happens behind the scene as compilation is done)



As a world premiere, here is a snapshot of an @AspectJ aspect in AJDT !

@AspectJ in AJDT

For those of you using AspectWerkz, you may wish to give it a try very soon, as it is already much better that the Eclipse plugin I had written for AspectWerkz, and as it will help you to get started with the @AspectJ syntax in your favorite IDE.

Start your download engines to get the next build snapshots and the upcoming AspectJ 1.5 M3 with your fresh Eclipse 3.1 final !

(Many thanks to Andrew and Mik for answering my questions to get that bits working)