| [aspectj-users] Re: Kudos, J2EE pointcuts, and Dynamic AOP |
Ron Bodkin wrote:Note that marker interfaces are very likely to become discouraged when JSR 175 (i.e. JDK 1.5) becomes final. The recommended way to do this will then become metadata.One can also write AspectJ aspects to address a handful of system-wide dynamic concerns that many POJOs might implement. If you made them all implement a _marker_ interface like Advisable (as JBoss does), then you can write advice with a test for whether this object is affected (using introductions or a hash map). I posted a few thoughts on TheServerSide thread about annotated concerns, which I pasted below. Any comments? The thread (Gregor's interview) can be found at: http://www.theserverside.com/home/thread.jsp?thread_id=20583&article_count=9 -- Cédric http://beust.com/weblog 
Annotated concerns
I notice that both of you use the same
example to illustrate pointcuts with annotations: readonly (or
changestate).
Intuitively, I feel that an AOP framework should support all types of pointcuts (both external and internal) but except for the above example, I can't find another convincing use case. Like Gregor, I have the feeling that annotated pointcuts should tell something generic about the method they are annotating, and not describe what it does. They should be conceptual. ChangeState is a good example, and I was thinking that something like Idempotent is another one: this indicates that this method can be called several times (stateless). An application could typically make use of that information to implement failover and retry a call that has just failed, knowing that it is not going to cause an inconsistency in the state of the application. How do you identify what a good "Annotated concern" is? Maybe a good hint is: it can be represented by very different implementations. An "annotated concern" like "ChangeState" is very broad indeed. A method can be one line long or a hundred lines long and still fall in this category. It can be called setPoint() or foo() and still deserve the annotation ChangeState. With this definition, UpdateDisplay immediately comes out as suspicious: it is way too specific and tied to the implementation. As would something like UpdateDatabase (how about the more generic "SaveState" instead?). But I am still annoyed at the poverty of examples to support this assertion. It's a bit like trying to advocate AOP by implementing logging in an aspect... if you repeat the same example over and over, you lose your ability to convince. I am also worried by the fragility of the regexp approach. If ever a developer renames a method or moves it to a different class, the pointcut might no longer find it. Worse: you can imagine a situation where you have two different developers: one who wrote the business code (let's call him B) and one wrote the aspect (A). And in the purest illustration of separation of concerns, B has no idea what aspects have been written around his code, so he doesn't even have the possibility to modify the aspect in parallel (which should raise concerns of coupling anyway). I think this is a real concern (no pun intended) in taking AOP to a big scale, especially since IDE's nowadays make it so easy to do major refactorings. |