Community
Participate
Working Groups
Build ID: M20090211-1700 Steps To Reproduce: I have two pieces of after advice in my aspect. In the cross reference view I see all of the joinpoints for both after advice selecting one of the after advice statements. When I select the other after advice statement I see no joinpoints. When I select the marker for either piece of after advice, I see all the joinpoints for both pieces of advice. 1. open and perform a clean compile on the attached project 2. open the xref view 3. select line 22 an note that you see 5 joinpoints (should only be 3) 4. select line 68 and note that you see zero joinpoints (should be 2 here) 5. right click the marker at line 68 and choose "advises" - note you see all 5 joinpoints 6. right click the marker at line 22 and choose "advises" - note you see all 5 joinpoints More information:
Do you have a test case for this? Or at least the pointcuts and advice you are using?
Created attachment 129472 [details] sample project sorry... I thought I had attached the project with the initial report. I guess it didn't take.
This is a handles problem. Both aspect advice have the same handle: =EnforceProcess/src<com.kronos.aspects*ProcessAspect.aj}ProcessAspect&after&QMyProcessor; However, the second advice should have the handle: =EnforceProcess/src<com.kronos.aspects*ProcessAspect.aj}ProcessAspect&after&QMyProcessor;!2 However, interesting thing is that when I trim the aspect down to this the problem goes away and all handles are generated correctly: public aspect ProcessAspect perthis(initMyProcessor(MyProcessor)) { HashMap<String, Field> fieldList = new HashMap<String, Field>(); pointcut initMyProcessor(MyProcessor myProcessor) : initialization(MyProcessor+.new(..)) && this(myProcessor); pointcut executesProcess(MyProcessor myProcessor) : execution(* MyProcessor+.process()) && this(myProcessor); // find all of the public fields or fields with public accessors after(MyProcessor myProcessor): initMyProcessor(myProcessor) { } after(MyProcessor myProcessor): executesProcess(myProcessor) && !cflowbelow(executesProcess(MyProcessor)){ } }
Moving this over to AspectJ because it is a handles problem.
the problem here is that the after method signatures are in fact different. One advice uses thisJoinPointStaticPart and the other does not - this introduces an extra parameter to the advice signature and thus they are considered different. I have to build in tolerance for this extra parameter and disregard it in advice signature counter calculations. In fact I have to build in tolerance for up to 3 parameters - thisJoinPoint, thisJoinPointStaticPart, thisEnclosingJoinPointStaticPart. The advice knows how many extra params were added, but in creation of the program element that information is lost so for now we will just strip them based on well known names (a better future fix would be to pass that data across to the programelement). The current fix could break if someone actively wrote an advice signature that specified a join point type... but who on earth would do that. I wonder how many users have been hitting this problem? Seems relatively serious so important to get this fix out fast.
proposed fix is committed into AspectJ and AJDT - should be in an AJDT build later today
tested the scenario described at the top of the bug report and this works fine on the latest AJDT dev build.
