Summary: | ordering issue with @annotation binding on field targeted by declare anno | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Andrew Clement <aclement> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | dominik.mengelt |
Version: | 1.7.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Mac OS X - Carbon (unsup.) | ||
Whiteboard: |
Description
Andrew Clement
2012-04-03 21:44:00 EDT
This problem also occurs in straight compilation if the files are passed in in a particular order. For example: === ajc Anno.java TriggerAll.java MyObject.java Main.java -1.5 -d . -showWeaveInfo 'public int myInt' of type 'ch.tests.MyObject' (MyObject.java) is annotated with @Anno field annotation from 'ch.aspects.TriggerAll' (TriggerAll.java:6) Join point 'field-set(int ch.tests.MyObject.myInt)' in Type 'ch.tests.MyObject' (MyObject.java:11) advised by before advice from 'ch.aspects.TriggerAll' (TriggerAll.java:8) Join point 'field-set(int ch.tests.MyObject.myInt)' in Type 'ch.tests.Main' (Main.java:7) advised by before advice from 'ch.aspects.TriggerAll' (TriggerAll.java:8) === ajc Anno.java Main.java TriggerAll.java MyObject.java -1.5 -d . -showWeaveInfo 'public int myInt' of type 'ch.tests.MyObject' (MyObject.java) is annotated with @Anno field annotation from 'ch.aspects.TriggerAll' (TriggerAll.java:6) Join point 'field-set(int ch.tests.MyObject.myInt)' in Type 'ch.tests.MyObject' (MyObject.java:11) advised by before advice from 'ch.aspects.TriggerAll' (TriggerAll.java:8) === Notice in the second case there is only one advised field-set. In the compilation case this is because at the time the match is attempted for @annotation() against the field-set joinpoint the type containing the field hasn't gone through the compiler and into the weaver. Therefore it hasn't been affected by the declare @field yet. When it works it is because the type is through into the weaver before the @annotation match is attempted. I imagine the LTW scenario is also ordering, so now I'll convert what i have into LTW tests. There are two bugs related to this specific issue: bug 133770 and bug 286473. These relate to the same problem which is matching against something that hasn't been through the weaver yet. Under 133770 the following option was added '-Xset:completeBinaryTypes=true' which can be set in weaver options. As discussed in 133770 it may misbehave when in a non-straightforward classloader configuration and so was turned OFF by default. Turning it ON doesn't fix the issue here though. That is because complete binary types wasn't enhanced to support declare @field/@method it was only built to handle declare parents and declare @type. Extending it to support declare @field makes the testcode pass just fine. > Extending it to support declare @field makes the testcode pass just fine.
Nice findings Andy. Thanks. Would be great to see another dev build.
dev build is on the download page now - try it out. Remember to use -Xset:completeBinaryTypes=true in the weaver options section of your aop.xml |