BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News InfoQ Article: Painless AOP with Groovy

InfoQ Article: Painless AOP with Groovy

This item in japanese

Bookmarks
Groovy's Metaobject-Protocol provides a single point of contact for modifying the core behaviour of the Objects we create. In this latest InfoQ article, John McClean shows how to use Groovy's MOP to perform AOP interception without proxyies or bytecode manipulation, and shows how the same is possible in Ruby and other dynamic languages.

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT