(I split this post out of another topic and forgot to include the following)
Craig Walls wrote:
This should probably be a new thread, but...I'll answer anyway...
Logging is one of the stock answers for what AOP is good for. And for an application that has no logging whatsoever already, AOP-driven logging is probably a good start. That said, as aspects can only apply a generic logging style across methods as they're invoked, a more precise insertion of logging calls within the code will produce better results. But again, you have nothing now, so AOP driven logging is certainly better than that.
Be aware that Spring AOP has one main limitation: It works by proxying Spring beans and therefore the aspect will not be applied to any components not configured as beans in Spring and even then will not work if the caller did not obtain the instance from the container (either by injection or by asking the container for it). Moreover, if the types you want to apply an aspect to do not have an interface that they implement, you'll have to use CGLIB-based proxying as opposed to JDK-based proxying. Spring can do either...you just need to be aware of the tradeoffs.
If the limitations of Spring AOP make it unworkable for you, then there's nothing wrong with using AspectJ to achieve your AOP goals. AspectJ gives you a more complete AOP model, but the tradeoff is either compile-time weaving vs. registering an agent to perform loadtime weaving.
meenakshi sundar wrote:In one of our existing legacy system with no logging mechanism of any sort built onto it ,the maintenance is becoming nightmarish
We have been exploring various options ,we have started a small POC on making use of Spring AOPs,We haven't yet thought about the big picture of its implication on the run time environment
Any thoughts on this would be greatly appreciated.
Thanks
