Community
Participate
Working Groups
If you write a privileged aspect that contains an ITD on some type and that ITD calls a private method in that type *and* you are trying to advise calls to that private method, the joinpoint in the ITD will not be found. This is vaguely similar to the problem in bug 307120 but there the issues was pipelining interfering (so that was a breakage introduced when pipelining was added), but here the problem is more serious and it has never worked in AspectJ. A similar change to that made for 307120 can cause the lookup for a synthetic method to succeed in BcelClassWeaver.matchInvokeInstruction() but the call further down to declaredSig.getEffectiveSignature() will not find a declared signature attribute. getEffectiveSignature is not implemented for the ResolvedMemberImpl that is discovered on jpSig.resolve(), it seems to only be supported for Bcel subtypes of Member. The solution is probably to ensure the effective signature is set correctly for the resolved member that gets created.
only going to look at this when someone hits it...
Created attachment 256311 [details] simple testcase I hit this problem this week and having a fix or a workaround would be nice. Would the fix be hard to implement? Or, even if I can't match the private call with a standard pointcut, could I rewrite it to match anyway? I would not mind a messy pointcut as long as it advises the private call. Thanks in advance for your feedback.
I pushed some changes to enable this. Unfortunately not the changes I originally thought I could do. I hoped to leverage the effective signature attribute but at the time we are weaving the ITD the target class may not have been through the weaver, so it will not have the accessor methods in it onto which the effective signature attribute can be attached. The simpler/dirtier thing is to recognize this specific situation in the BcelClassWeaver.matchInvokeInstruction and handle it as a special case. All the other tests we have are fine with this change so committed it. I added one more testcase beyond the one attached here (thanks for that) - it could really do with more testing though. Perhaps in your real scenario things are more complicated than in the testcase - any problems then let me know.
