When I was researching for an AOP framework I was first very excited about Spring AOP[1] due to obvious reasons: integration with Spring and no need for an extra compilation step or runtime weaver.
But then got disapointed by its limitations.
For instance, Spring AOP works only by proxying Spring registered beans. No way to advise an object that's not a Spring bean.
With AspectJ[2] you can do whatever you want on objects of any class, with the catch of either adding compilation step for the pre processor to convert AOP idioms into woven classes, or use the runtime weaving by passing a VM argument.
I for instance made an exploratory prototype for gathering the requests statistics information needed for an hypothetical monitoring module, and found that runtime weaving is just as easy to implement _and_ to debug. Moreover, there are quite a bunch of information that couldn't have been gathered with Spring AOP, whilst with AspectJ it was possible to gather all the required information in a single aspect, advising methods from the Dispatcher and FeatureTypeInfo, neither of which is a Spring bean.
From the Spring AOP documentation <http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-spring-or-aspectj>:
"Use the simplest thing that can work. Spring AOP is simpler than using full AspectJ as there is no requirement to introduce the AspectJ compiler / weaver into your development and build processes. If you only need to advise the execution of operations on Spring beans, then Spring AOP is the right choice. If you need to advise objects not managed by the Spring container (such as domain objects typically), then you will need to use AspectJ. You will also need to use AspectJ if you wish to advise join points other than simple method executions (for example, field get or set join points, and so on)."
Finally, AspectJ is in itself an eclipse project now, and wrt IDE integration, AspectJ comes with plugins for eclipse, JBuilder, NetBeans, JDeveloper, Emacs and JDEE; and the AspectJ In Action book is quite good.
Those are the reasons I favor AspectJ over Spring AOP. Though at a first glance I would have liked to keep tied to Spring instead of introducing an extra framework and runtime weaver.
My 2c/
Gabriel
[1] <http://static.springsource.org/spring/docs/2.5.x/reference/aop.html>
[2] <http://www.eclipse.org/aspectj/>
Justin Deoliveira wrote:
I did some trivial aspectj experimenting back in 2002 and have done a bit with spring aop here and there. What I have found (and who knows if this is still valid) is that aspjectj seems to be more powerful as an AOP technology but at the end of the day they more or less do the same thing.
I would tend to favor spring AOP just based on the fact that (a) we already use it for some stuff (look at the EMFLogger class) and (b) we are deeply dependent on spring already.
There is also the question of which project is more active. It seems like aspjectj is making a comeback? But I don't think it has the legs under it that spring does.
2c.
-Justin
Andrea Aime wrote:
Hi,
as a curiosity, what is people opinion on starting to use
AspectJ in GeoServer?
The library is still being developed (a new release is just
a few days old: http://www.eclipse.org/aspectj/) and
there has been books about it, but it never became
mainstream (not as Spring, Hibernate and some other libraries
are, at least)
The idea behind using AspectJ would be monitoring and control
of sorts, instead of rolling listeners pretty much anywhere
we could introduce aspects that are weaved in at runtime.
The idea is actually coming from Gabriel, but I guess he's
too shy or busy to ask, so I decided to go ahead and see
what people think.
Also, does anyone have familiarity with Spring own AOP
support?
http://static.springsource.org/spring/docs/2.5.x/reference/aop.html
Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
).