Community
Participate
Working Groups
check delta between Aj and @aj (infinite recursion)
@advice execution match by execution ?: should not pick advice execution - OK (see BcelClassWeaver.match(LazyMethoGen) - KO (the pointcut parser will match, not looking if it is a @advice) (should fix the pointcut parser) => TODO @advice call match by call ?: should not pick call to @advice (since in aj user cannot call advice explicitly) [or should they - that s debatable...] [+ meta-aspect, and @Aspect are actually java class anyway] - Now: it match - If to not match: should fix SignaturePattern (ie the grammar itself must say no match for f.e. 3rd party tools using the pointcut parser directly and not the weaver) => TODO @aspect aspectof match by call/execution ? call cannot be made on src @aspect (needs Aspects.aspectOf reflective) but might be made on ajc @aspect since aspectof is introduced - need to check this one (signature pattern aspectOf and decl type is @Aspect or something like that, both for call and execution - providing code style does the same and skip aspectOf() call/execution matching => TODO
@advice execution match by execution ?: should not pick advice execution -> the execution of advice should not be matched by an execution join point. It *should* be matched by an adviceexecution join point. We lose the nice ability to match on name, parameters etc., but that should be fixed by extending the adviceexecution form to allow this (maybe post 1.5) rather than giving the wrong kind of join point. @advice call match by call ?: should not pick call to @advice (since in aj user cannot call advice explicitly) [or should they - that s debatable...] -> interesting. In a code-style aspect program there is simply no way to call advice, so this can't happen. In an @AJ style program there is a very simple way to call advice. We once talked about having a special Checker (declare error) in the weaver that matched on any call to a method annotated with @advice. This would give the exact same capabilities as code-style, but it seems a bit draconian when direct calling makes it easy to write unit tests and I don't want to forbid that. I'm tempted to say that if you do explicitly call an "advice" you *do* get a call join point. @aspect aspectof match by call/execution ? -> calls should match as per the users program (so a piece of user code MyAspect.aspectOf() is a call to call(* aspectOf(..)), but the aspectOf calls inserted as part of the weaving process are *not* matched. A call to Aspects.aspectOf(..) should be matched by a call pcd matching that signature (no special fudging). We don't support execution join points for aspectOf, should probably do the same for Aspects.aspectOf ? (if for no other reason than weaving aspectOf can really screw up weaving!)
ok thanks note: Aspects.aspectOf can only have call jp as it is in org.aspectj.* I was talking only about the weaved in (compiled in) aspectOf(..) method in the advice - so this one does not gets matched for execution jp, and **does** get matched for call jp when the call is not one that we weaved in. Since for @AJ aspect, the aspectOf() is called - wether from Aspects.aspectOf, reflectively - wether directly if aspect was available in binary form this might mean some idiom to match them in both case - unfortunately, + some more invasive pointcut to match Aspects.aspectOf(..) on the aspect I am interested in only. (correct me if this is wrong)
raising to P2
moving out beyond the RC, we need to put something out!
really must make a decision on this !
...
It appears that adviceexecution pointcuts still don't match annotation-defined advice. That's a real problem if you are relying on adviceexecution to match, e.g., it causes problems for those using annotation aspects to extend Glassbox.
resurrection
I just wrote this program -- A.java -- import org.aspectj.lang.annotation.*; @Aspect public class A { public void m() { } @Before("adviceexecution()") public void advice() { } } aspect B { before(): adviceexecution() {} } ------------ And it worked as expected: ajc -1.5 A.java -showWeaveInfo Join point 'adviceexecution(void B.ajc$before$B$1$1ff5cffd())' in Type 'B' (A.java:17) advised by before advice from 'B' (A.java:17) Join point 'adviceexecution(void B.ajc$before$B$1$1ff5cffd())' in Type 'B' (A.java:17) advised by before advice from 'A' (A.java:10) Join point 'adviceexecution(void A.advice())' in Type 'A' (A.java:10) advised by before advice from 'B' (A.java:17) Join point 'adviceexecution(void A.advice())' in Type 'A' (A.java:10) advised by before advice from 'A' (A.java:10) So what isn't working?
appears to be working from my most recent comment, will revisit if this comes up again
