Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 359159 - construction of entire aspects using aop.xml
Summary: construction of entire aspects using aop.xml
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 enhancement (vote)
Target Milestone: 1.6.12   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-27 21:14 EDT by Andrew Clement CLA
Modified: 2011-09-28 11:02 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Clement CLA 2011-09-27 21:14:15 EDT
Currently the ability to customize aspects in aop.xml is quite limited.  Basically for some abstract aspect with an abstract pointcut, the XML can concretize the pointcut.  This still requires the user to have used the AspectJ compiler to build the abstract aspect. 

It might be nice if that need to use the AspectJ compiler was not necessary in common cases.
Comment 1 Andrew Clement CLA 2011-09-28 11:02:26 EDT
basic version committed.  We don't want to go as far as allowing java code to be written in the XML, so what we have now is that you can define a pointcut and link it to a Java method.   AspectJ will then generate an aspect containing the necessary advice construct and that advice will simply delegate to the Java method that was selected.  Currently supports before/after/around advice - but doesn't allow differentiation between after returning and after throwing (those can be added by whoever first wants the support!).  proceed works too. 

Examples:

<aspects>
    <concrete-aspect name="ConjuredUp">
      <before pointcut="execution(* Hello2.say2(..)) AND args(w) " invokeClass="JavaHelper" invokeMethod="advice2(java.lang.String w)"/>
    </concrete-aspect>
  </aspects>

public class JavaHelper {
 public static void advice2(String s) {
    System.out.println("in advice: s="+s);
  }
}

(notice arg binding is done based on the names in the XML file, not the names in the delegate method)


<concrete-aspect name="ConjuredUp">
      <before pointcut="execution(* Hello2.say2(..)) AND args(w) " invokeClass="JavaHelper" invokeMethod="advice4(JoinPoint tjp, java.lang.String w)"/>
      <after pointcut="execution(* Hello2.say2(..)) AND args(w) " invokeClass="JavaHelper" invokeMethod="advice5(JoinPoint tjp, java.lang.String w)"/>
    </concrete-aspect>

public static void advice4(org.aspectj.lang.JoinPoint tjp, String s) {
    System.out.println("in advice4: s="+s+" at "+tjp);
  }
  public static void advice5(org.aspectj.lang.JoinPoint tjp, String s) {
    System.out.println("in advice5: s="+s+" at "+tjp);
  }

(notice types are fully specified *except* JoinPoint since we know what that one is they can just use the unqualifed name in the XML)

There is more checking that could be done which I haven't added yet (e.g. whether the selected method is static).  A similar model could be extended to support any declares too (anntation/parents).
Comment 2 Andrew Clement CLA 2011-09-28 11:02:44 EDT
complete enough for now.