Practical use of AOP/AspectJ in projects

[Karthik Guru]

Does AOP make sense only for container and framework implementers?
Has anyone used AspectJ successfully in custom projects?. By 'use' I mean has anyone put AOP to considerable use in their projects?

[Valentin Crettaz]

Personally, AOP has helped me a lot in my projects. I have found AOP to be a very good complement of OOP. The most difficult thing to do is to find the correct synergy between AOP and OOP. Once you get it, you can do very elegant thing and leverage the power of both paradigms. Note that I deliberately talk about AOP and not necessarly about AspectJ. I have been using AspectJ since its inception and I have some concerns with it. There are many AOP solutions out there (AspectJ, AspectWerkz, Spring, JBoss AOP, Nanning, etc).

Below are some discussions about this matter:
AspectJ for Complex Projects
AspectJ and AOP in general
more hits

I have also written some book reviews on this subject:
Aspect-Oriented Programming With AspectJ by Ivan Kiselev
Mastering AspectJ by Joseph D. Gradecki, Nicholas Lesiecki
AspectJ in Action by Ramnivas Laddad
[ August 04, 2004: Message edited by: Valentin Crettaz ]

[Karthik Guru]

Thanks valentin for the links. I have read your blogs on aop and its really cool. I saw the code snippet in your blog and it looks neat. One question that i'm right now finding it difficult to answer is " What is an Aspect? "

So anything cross cutting is an aspect?. At what level does this apply?. Does it need to cut across classes in a package,system or even one class is enough. For eg how did you decide that the notification to the observers needs to be implemented as an aspect.

I mean could it be something like you see some common method being repeatedly called from other methods (in this case all mutators), you would code it as an aspect that applies to that class?

I have been looking at Aspectj for last one week and I was looking for couple of places where i c'd apply aop.

Struts declarative exception handling came to my mind, I thought that can be acheived by writing an 'after' aspect that traps all/some struts Action+.execute( ) methods and checks for the exception type thrown and do something.

We use a servlet filter too in our app and even that looks like a prime candidate for AOP.

thanks.

[Karthik Guru]

How does the code show up while debugging? I was wondering about the maintanance part too. The class on which aspects are applied are not aware of the aspect themselves which obviously is a good thing. Does IDE features help in anyways. I mean somebody debugging the class needs to be aware of the aspects that are getting applied to that class. Do IDEs help me link them somehow so that both of them show up together

How do you maintain the aspects in the source control? A separate package for just aspects/something else. Guess for Junit test cases one of the options is to maintain the same package structure albeit in a different folder from the source. I guess we dont have any *visibility* problems wrt aspects.

I mean

/<view-home>
src/
test/


And yes on the primary difference between aspect- j and werkz that you have higlighted (one being applied at compile time while the other at runtime), if I use aspectj with say weblogic, it w'd mean that i w'd have to instrument weblogic classes as well?. W'd BEA approve of this when I distribute my application with a modified weblogic.jar for example?
Does that mean that AspectWerkz is the way to go in such situations?

[Peter den Haan]

Originally posted by karthik Guru:
Has anyone used AspectJ successfully in custom projects?. By 'use' I mean has anyone put AOP to considerable use in their projects?

We use Spring AOP extensively in all our current projects. I should perhaps add that this is about coarse-grained AOP, usually applied against business objects, rather than the fine-grained pervasive AOP that AspectJ invites you to write. In that, it is evolutionary rather than revolutionary.

A selection of the uses we're putting it to:

Transaction demarcation (of course). Source-level attributes are used to apply transactional advice against business methods. This is out of the box Spring functionality.

Security constraints. Both role-based and data-based security constraint advice is applied against business objects. It is striking how simple writing advice is once you "get" it, and how much clutter you can pull out of your business objects.

We have an architecture whereby each module exports one object. In a few cases, we need to export more than one business interface implemented by more than one object, and we use introduction advice to merge them together.

Journaling in a little messaging framework.

Logging, of course

How does the code show up while debugging?

In Spring's case, if you advice interfaces, you see a Java dynamic proxy and the associated Spring invocation handler. It's actually quite straightforward when you step through it with a debugger. I've not used cgilib-based (class) advice in anger.

- Peter

[Karthik Guru]

Thanks Peter.

Originally posted by Peter den Haan:

We have an architecture whereby each module exports one object. In a few cases, we need to export more than one business interface implemented by more than one object, and we use introduction advice to merge them together.

Could you expand on this more? Some pseudo code would help. I am just trying to understand as to how this was a compelling case for applying AOP. + wanted some concrete examples of introduction advice that were put to use in live projects. Other features that you implemented using AOP makes sense.

thanks,
karthik

[Peter den Haan]

Originally posted by karthik Guru:
Could you expand on this more? [...]

It's not a compelling AOP use case, but it was pretty convenient regardless. The basic problem was that we had an object FooImpl implementing Foo, an object BarImpl implementing Bar, and needed to expose both Foo and Bar as a single object. Without AOP, you might write something like

public class FooBarFacade implements Foo, Bar {
   private Foo foo;
   private Bar bar;
   public void fooMethod1() { foo.fooMethod1(); }
   public void fooMethod2() { foo.fooMethod2(); }
   public void barMethod1() { bar.barMethod1(); }
   public void barMethod2() { bar.barMethod2(); }
   ... and so on, and so forth...
}

With AOP, we just introduced interface Bar implemented by BarImpl into Foo. The result is a Java proxy implementing both Foo and Bar, and delegating calls to FooImpl and BarImpl as appropriate.

You can easily do this yourself - either laboriously as quoted above, or using a proxy and a little InvocationHandler - but nowhere near as easily as a few lines of AOP configuration.

- Peter