Read Painless AOP with Groovy
Dynamic languages like Groovy make implementing custom-AOP infrastructure painless. There is no requirement for byte-code modification, and the infrastructure code base can be kept small so as to be readily understandable by new developers. Groovy's MetaObject-Protocol allows us to mould our Object's behavoiur to suit the problem at hand and first class functions and dynamic typing makes dynamically inserting functionality relatively easy.
Community comments
Nice Article
by John Wilson,
Re: Nice Article
by Jeff Payne,
Re: Nice Article
by John McClean,
Re: Nice Article
by Martin Gilday,
Re: Nice Article
by Matthias K.,
Re: Nice Article
by John McClean,
Re: Nice Article
by Chris Mead,
Documentation
by Horia Muntean,
Re: Documentation
by John Wilson,
Nice Article
by John Wilson,
Your message is awaiting moderation. Thank you for participating in the discussion.
That was very clear. I think this is the easisest way of doing AOP in Groovy but it is not the most powerful. With custom MetaClasses you can do AOP in a completely non intrusive manner and you can apply AOP to POJOs as well as POGOs.
Perhaps you might conside a part 2?
John Wilson
Documentation
by Horia Muntean,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hopefully this is a sign that the 'new MOP' of Groovy is starting to get some documentation.
Re: Documentation
by John Wilson,
Your message is awaiting moderation. Thank you for participating in the discussion.
From a user's point of view the "new MOP" is very close to the old one. (really just the way missing methods and properties are reported). The main changes that the "new MOP" intoduces are designed to be used by the compiler. In fact we have recently discovered that we can pass type information (which is one of the main motivations for the "new MOP") without having to change the API at all.
Re: Nice Article
by Jeff Payne,
Your message is awaiting moderation. Thank you for participating in the discussion.
True. Although these examples are very easy to understand, modifying the classes at runtime using object.metaClass instead of at design time doesn't couple your classes to AopObject, etc. POGO/POJOs need not know that their methods are being intercepted. Should be fairly easy to implement an AOP framework to allow for defining advice code (maybe in the form of closures). I'm new to Groovy and glad to see that it has these abilities.
Re: Nice Article
by John McClean,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks John. Re: custom meta-classes, sounds interesting, I would certainly consider writing a part 2. I wonder if infoQ would consider publishing it?
Re: Nice Article
by Martin Gilday,
Your message is awaiting moderation. Thank you for participating in the discussion.
I would certainly be interested in more articles being published here on this topic, and other uses of Groovy.
Re: Nice Article
by Matthias K.,
Your message is awaiting moderation. Thank you for participating in the discussion.
First of all, thanks a lot for this article, I was looking into Spring AOP in Grails and found that it's not capable enough (try intercepting closures with Spring...) so this may be the better way instead.
However, has anyone actually tried to run this code? For me it continually recurses into invokeMethod(), resulting in a stack overflow... duh!
Apart from that, there are some things odd or unclear about the code. Why does AopObject inherit from GroovyObjectSupport? It's a Groovy class, thus it already inherits invokeMethod() naturally. GroovyObjectSupport, according to the documentation, is only meaningful when programming in Java.
The proceed field furthermore is assigned a superfluous closure. You can simply assign continueWith to proceed:
callDetails.proceed = continueWith
That's the idea behind closures... they're addressable pieces of code and can be passed around.
Any help appreciated on that recursion problem though... don't know why a call to super.invokeMethod invokes the same overridden method again.
Re: Nice Article
by John McClean,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Mattias,
The Groovy internals changed significantly in the two years between the original article and your comment, I imagine that is the cause of the infinite recursion.
It's much simpler to do the same thing with Metaclasses these days.
Re: Nice Article
by Chris Mead,
Your message is awaiting moderation. Thank you for participating in the discussion.
Again, thanks for the article. It may be old, but it is at the top of related Google searches.
I fixed a couple issues. I am not sure if I am 100% correct as I am only using before and after for now.
1) Add "def proceed" to AopDetails
2) Make sure that your AopObject matches what is onscreen here. I had to remove a method called callInvokeSuper() and simply use "super.invokeMethod(name,args)" instead (which is what is in the screenshot.)
Good luck.