Community
Participate
Working Groups
Created attachment 142672 [details] demo project and screenshot Build ID: 20090621-0832 Steps To Reproduce: 1. create a class with a method to be adviced 2. create an aspect with advice (to intercept the method created in step 1) body referencing 'thisJoinPoint' (e.g. System.out.println(thisJoinPoint) 3. build project and check the cross reference views and editor gutter marker pop-up information. ***the information shown in incorrect in cross reference view and editor gutter More information: a eclipse project to demo the problem and 2 screenshots (s1.jpg and s1.jpg) are attached software info: eclipse: 3.5 AJDT: 2.0 JDK: sun jdk 1.6 update 14
Just to be clear here. The pointcut p1() should not be matching the methods in ParentIntObj and ChildIntObj. When the aspect is reduced to only include the advice attached to p1(), the gutter markers and relationships are correct (2 advised locations) When the aspect is reduced to only include the advice attached to p3(), the gutter markers and relationships are correct (2 advised locations) When both the advices for p1() and p3() are in the aspect, they both inherit each others relationships and show 4 advised locations each. In this situation with both pieces of advice active. The relationship map is: Relationship map: =MyMonitoringTool/src<test{ChildIntObj.java[ChildIntObj~doNewTT~QString; :: =MyMonitoringTool/src<test{ChildIntObj.java[ChildIntObj~doNewTT~QString; --advised by--> [=MyMonitoringTool/src<test*AspectTrace.aj}AspectTrace&before] =MyMonitoringTool/src<test{ParentIntObj.java[ParentIntObj~doNewTT~QString; :: =MyMonitoringTool/src<test{ParentIntObj.java[ParentIntObj~doNewTT~QString; --advised by--> [=MyMonitoringTool/src<test*AspectTrace.aj}AspectTrace&before] =MyMonitoringTool/src<test*AspectTrace.aj}AspectTrace&before :: =MyMonitoringTool/src<test*AspectTrace.aj}AspectTrace&before --advises--> [=MyMonitoringTool/src<test{ParentIntObj.java[ParentIntObj~doNewTT~QString;, =MyMonitoringTool/src<test{Parent.java[Parent~doTT~QString;, =MyMonitoringTool/src<test{ChildIntObj.java[ChildIntObj~doNewTT~QString;, =MyMonitoringTool/src<test{Child.java[Child~doTT~QString;] =MyMonitoringTool/src<test{Child.java[Child~doTT~QString; :: =MyMonitoringTool/src<test{Child.java[Child~doTT~QString; --advised by--> [=MyMonitoringTool/src<test*AspectTrace.aj}AspectTrace&before] =MyMonitoringTool/src<test{Parent.java[Parent~doTT~QString; :: =MyMonitoringTool/src<test{Parent.java[Parent~doTT~QString; --advised by--> [=MyMonitoringTool/src<test*AspectTrace.aj}AspectTrace&before] Due to their only being one 'advises' relationship, the problem is that the handles generated for the two pieces of advice are the same. In bytecode the names are different because the generated method name for the advice includes the hashcode of the pointcut text. But that is not included in the handle construction.
Second thoughts - if that final statement I made in the previous comment really were the problem then everyone would be seeing this bug. On investigating further the actual additional 'requirement' here that leads to the problem is that the advice uses thisJoinPoint. The signature handling for the advice and any peer-advice that it is being compared against differs and this can lead to two signatures being considered different when they are in fact the same. Fixing it to be consistent and manipulate all signatures in the same way causes us to notice the advice signatures are the same and so the second advice gets a counter suffix !2. This fixes the problem. test and fix committed. thanks for the test program.
