Community
Participate
Working Groups
for M4 note: need to think some if we want to jit the concrete aspect, or if its not that needed ie that the shadow munger API allow us to do what we need (perhaps not easy to deal with perClause and uniqueness enforcement of concrete-aspect name, but perhaps a burden as well to deal with jit since then no bytecode can be grabbed from file system ie may confuse the bcel repository and resolvedTypeX and alike) Ideas Andy ? I am more in favor of bytecode gen the concrete aspect there. (that further means the underlying infra needs to support define class callbacks like "acceptClass" thing used for ajc$Closure and alike when running LTW. I am ok with that)
marking as "enhancement" to make it easier to distinguish between new function to be implemented in M4 and bugs to be fixed.
Raising to P2 to ensure we resolve this in the run-up to AJ5 RC1
Some notes: @Aspect abstract class MyA { @Before("pc()") .... {..} @Pointcut // see here, nothing defined ie default "" in annotation abstract void pc(); // must be abstract for @Pointcut() to be allowed } // note: If AJC + run: as we have an abstract aspect, the before advice is not // applied Scenario A ---------- aop.xml contains: <aspect name="MyA"/> // ie refers an abstract aspect --> what should happen? I think it is an error, and we report it as such Scenario B ---------- aop.xml contains: <aspect name="MyA_Real" extends="MyA"> <pointcut name="pc" expression="..."/> </aspect> --> checks as follow: - MyA is abstract - Every abstract poincut from MyA is defined in XML <pointcut elements - Only void and (noargs) method are allowed (ie not: <pointcut name="pc(a)" expression="... && target(a)" /> with lookup of binding for void pc(SomeType x) etc) [that means only simple pointcut can be xml-defined] comments?
impl done some notes: concrete aspect is JIT generated, using @AspectJ style @Aspect // ie per from super public class My extends Asbtract { @Pointcut(.... the expr from xml) mods.. void pc() {} //mods must obey OO rules here } this ones is then passed thru the munger for aspectof method to be added (this does NOT follow the regular process - which assumes as configured weaver, as we are precisely doing the config at that stage). doc updated with sample
spotted that decl precedence cannot be late defined. added some xml for that (that again is turned to an @AJ annotation) <concrete-aspect.... precedence="..."> ...
impl commited work pending on ajdt core to not complain on asbtract @Pointcut and do some checks (abstract ()V method only)
all done TODO = test on error reporting
This looks great however: - Declaring an abstract aspect is quite valid because it may have an effect even if not made concrete e.g. ITDs (see http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg04545.html). I am working on a testcase. - The support for precedence has not been fully specified. The user should be able to define it without having to extend an existing aspect as can be done with the AspectJ syntax. There is an enhancement request for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=106504 - Testing error messages will be much easier using the new LTW support in the harness. I have started the work and will post a patch when I have one. We can reuse all the expected message handling that exists for the “compile” task.
Created attachment 28914 [details] Testcase for abstract LTW aspect and harness improvements This started as a simple LTW ITD testcase but needed several small changes to the harness and weaving adaptor to get consistent message handling. It also contains a test for empty aop.xml files.
Created attachment 29186 [details] Patch for loadtime, weaver, ... 1. Improved test for empty aop.xml 2. Avoid creating duplicate world/weaver in WeavingAdaptor.init()
Do we need to integrate Matthews patches here?
Now that bug 95516 is complete we need to remove the warning about abstract aspects being declared in aop.xml.
Created attachment 29771 [details] Updated patch 1. Test weaving adaptor disabled and message issued when no aop.xml found 2. Test declaration and side effect of an abstract aspect
as per discussion on call yesterday, new patch integrated. will close when build available.
code available in latest dev build.
