Is using Spring AOP for logging a good idea?

Question

I'm reading up on Spring at the moment and one of the examples used for a use of AOP is logging the start and end of method calls.

I've also read that using AOP can impact performance.

Is using Spring AOP a good idea for this type of logging? My understanding is that Spring uses Dynamic AOP would it be be better to use Static AOP (Like AspectJ) for this type of AOP.

Curently the coding policy of the company I work for requires a ridiculous amount of logging and i want to reduce the ammount of logging code I have to write and improve the readability of my code.

Am I barking up the wrong tree?

Answer 1

Read this blog-post about your performance concerns.

The way to think of AOP is to put the provided functional benefits in the first place. If automated logging is your requirement and AOP fits it - go for it.

That said, load-time weaving is, of course, preferred if fine-grained logging is required.

Answer 2

I used Spring AOP for implementing logging so I share my observations:

• Performance impact is not sufficient, it is less than impact of logging itself
• Having aspects configured in Spring configuration, you are able to completely disable logging code if necessary
• Debugging becomes more problematic as stack traces become rather longer
• Such decision sufficiently affects design. It is not only that you get a bunch of interfaces and aspect classes, but you production classes must be very "thin". Don't forget, you are unable to intercept calls to non-public methods. Self-calls (even to public methods) also cannot be intercepted (as you working with naked this handle instead of handle wrapped by AOP) and thus cannot be logged. So all logging can happen only on interface boundaries. (This concerns using Proxy-based aspect weaving, there's an option of runtime subclassing with cglib, but I didn't use it)
• Writing pointcuts can be very tricky. IntelliJ Idea helps greatly determining which methods are to be adviced by pointcut.
• Generally, I liked this approach and think it is worth using, but it appeared far more complicated than I expected