Community
Participate
Working Groups
Preface ======= This enhancement request is a result of mailing list discussion in this thread: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg13680.html Specifically Andy Clement's last message in which he suggests that I may open such a request made me do this: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg13687.html Enhancement request =================== From my point of view as an AspectJ user it would be desireable to make "proceed()" in "around()" advice a joinpoint so as to be able to intercept it with a pointcut. Currently this just slips through my net when I try to advise another advice, it is impossible to capture. The only workaround is to copy and paste all the other pointcuts used by the (multiple) "around()" advice of which I want to capture "proceed()" like this: pointcut captureProceed(): pointcut_1() || pointcut_2() || ... || pointcut_n(); I also have to make sure that the advice using "captureProceed()" is matched *after* all the other advice using "pointcut_*". Another workaround is using the *worker object pattern* (see "AspectJ in Action, 2nd edition", chapter 12.1) in order to repeat code duplication when trying to capture "proceed()". I even think that the inability of AspcetJ to intercept "proceed()" by native language means could be the main reason for Ramnivas Laddad to have needed and found/invented that pattern at all. Possible advantages ------------------- - the ability to efficiently re-advise existing "around()" advice which might only be available as class files and capture their "proceed()" calls/executions - no more need to use the worker object pattern in this situation (the pattern still has its other natural use cases left, such as multi-threading or scheduling/queuing) - less code duplication means better maintainability of aspects - increased expressiveness of the AspectJ language Possible disadvantages ---------------------- Andy Clement wrote: > I am always extremely careful about introducing new joinpoints as suddenly > they will be matched by all pointcuts out there which were not written to > exclude them (because they didn't know theyneeded to). This could be avoided by introducing a special pointcut (similar to "adviceexecution"), maybe with a name like "proceedexecution". > The most recently added array related joinpoints still only exist if > deliberately switched on by the user via an option. I did not even know those joinpoints exist. I need to check the documentation. ;-) Anyway, I guess it would be acceptable to explicitly enable something like "proceedexecution" joinpoints if tests shown that there might be side effects. The only side effects I can imagine is a "catch all" pointcut matching all joinpoints (or at least all cflow of an advice execution). I am aware of the fact that chances to get this enhancement implemented are kind of low, but I do hope that we might get this new idea on the way if others also find it useful. I definitely do because I had cases in which I needed to summon up all my fantasy to overcome this limitation with all kinds of more or less dirty tricks.
