Is using Spring AOP for logging a good idea?
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.
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
I did it similarly to the way described in this blog post. It's the best I found and it also has a sample that shows nicely the difference between using and not using AOP.
Imho it isn't worth it, unless you're doing something fancier then logging, like error management with persistence. If you have a good exception hierarchy (domain, system) and properly set logging boundaries, you wont reduce much logging code.