Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Overriding pointcuts

> The problems arise when I have 
> pointcuts
> that expect arguments, as in the fifo example.

For me your code works when fifo is bound in all legs of the pointcut:

----
aspect ExtLogging extends Logging {
  pointcut log(Fifo fifo) : Logging.log(fifo) || 
    (this(fifo) && execution(* Fifo.Get(..)));
}
----

Wes



> ------------Original Message------------
> From: apel@xxxxxxxxxxxxxxxxxxxxxxx
> To: "Wes Isberg" <wes@xxxxxxxxxxxxxx>, rbodkin@xxxxxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
> Date: Fri, Oct-21-2005 1:34 PM
> Subject: RE: [aspectj-users] Overriding pointcuts
>
> Hi Wes and Rod,
> 
> I know that this example works. The problems arise when I have 
> pointcuts
> that expect arguments, as in the fifo example.
> 
> By the way, in a recent paper we propose the notion of aspect 
> refinement:
> http://wwwiti.cs.uni-magdeburg.de/~apel/AOASIA2005.pdf
> With aspect refinement it is possible to use the "super" keyword to 
> refer
> to the parent pointcuts. In this way we can extend or constrain the set 
> of
> join points using a subsequent subaspect. Unfortunately, this is 
> currently
> implemented in FeatureC++/AspectC++ only:
> http://wwwiti.cs.uni-magdeburg.de/iti_db/forschung/fop/featurec/
> Currently, we work on a version for AspectJ, using the abc. In fact, I 
> ask
> these questions to get insight in the semantics of AspectJ to implement
> aspect refinement in AspectJ. In an upcoming report we explain more
> details about our extension of AspectJ, including the things about
> pointcuts (we plan to publish the report next week).
> 
> best regards
> 
> Sven
> 
> 
> > Oh, good.  You're right that non-abstract pointcuts can also be 
> overridden
> > and not just hidden (meaning the superaspect uses the subaspect
> > declaration) - when the (implicit) reference is not a class.
> > Note in this light that you can refer directly to the superaspect
> > pointcut using a class/type reference:
> >
> > ----
> > abstract aspect AA {
> >     pointcut pc() : execution(void main(String[]));
> >     before() : pc() { System.out.println("jp: " + thisJoinPoint); }
> > }
> > aspect A extends AA {
> >     // AA.pc() refers to superaspect pointcut
> >     pointcut pc() : AA.pc() || (withincode(void main(String[]))
> >         && call(void PrintStream.println(String)));
> > }
> > ----
> >
> > It's too bad that using super as a reference is illegal:
> >
> > ----
> >     // error
> >     pointcut pc() : super.pc() || ...
> > ----
> >
> > It's when the pointcut reference is a class/type that hiding
> > comes into play, and can support a limited form of redeclaration
> > for external (class-reference) clients, e.g., of a library:
> >
> >   
> http://eclipse.org/aspectj/sample-code.html#library-classPointcutLibrary
> >
> > I'll document this somewhere, as long as Andrew/Adrian/Erik, et al
> > don't say it's accidental.
> >
> > Wes
> >
> >> ------------Original Message------------
> >> From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
> >> To: "'Wes Isberg'" <wes@xxxxxxxxxxxxxx>, aspectj-users@xxxxxxxxxxx
> >> Date: Fri, Oct-21-2005 11:24 AM
> >> Subject: RE: [aspectj-users] Overriding pointcuts
> >>
> >> Thatâ&#8364;&#8482;s not how I read the programmerâ&#8364;&#8482;s
> guide. From
> >> 
> http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.ht
> >> ml
> >>
> >> "Pointcuts that are not final may be declared abstract, and defined
> >> without
> >> a body. Abstract pointcuts may only be declared within abstract
> >> aspects.
> >>   abstract aspect A {
> >>       abstract pointcut publicCall(int i);
> >>   }
> >>
> >> In such a case, an extending aspect may override the abstract 
> pointcut.
> >>
> >>   aspect B extends A {
> >>       pointcut publicCall(int i): call(public Foo.m(int)) && 
> args(i);
> >>   }
> >> For completeness, a pointcut with a declaration may be declared 
> final.
> >>
> >> Though named pointcut declarations appear somewhat like method
> >> declarations,
> >> and can be overridden in subaspects, they cannot be overloaded. It 
> is
> >> an
> >> error for two pointcuts to be named with the same name in the same
> >> class or
> >> aspect declaration. "
> >>
> >> Notice that pointcut declarations can be overridden in subaspects. 
> The
> >> sentence does not limit them to abstract pointcuts.
> >>
> >> Moreover, the feature works as I read the description and I have 
> found
> >> it
> >> useful as in my earlier posting about how I used pointcut overriding
> >> for the
> >> glassbox inspector. Here is a simple xample:
> >>
> >> public abstract aspect Base {
> >>     public pointcut methodExec();
> >>     before() : methodExec() {
> >> 	System.out.println("advised by "+this);
> >>     }
> >>
> >>     public static void main(String args[]) {}
> >> }
> >>
> >> aspect Derived1 extends Base {
> >>     public pointcut methodExec() : execution(* main(..));
> >> }
> >>
> >> aspect Derived2 extends Base {}
> >>
> >> C:\devel\scratch\override>ajc Base.aj
> >>
> >> C:\devel\scratch\override>java Base
> >> advised by Derived1@12c1c0
> >>
> >>
> >>
> >>
> >> ________________________________________
> >> From: aspectj-users-bounces@xxxxxxxxxxx
> >> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes Isberg
> >> Sent: Friday, October 21, 2005 10:56 AM
> >> To: aspectj-users@xxxxxxxxxxx
> >> Subject: Re: [aspectj-users] Overriding pointcuts
> >>
> >> Also, Pointcuts are like static methods: they can be hidden but not
> >> overridden.
> >> And you cannot overload a pointcut name (e.g., with more or fewer
> >> variables).
> >>  
> >> In this case the advice in the abstract aspect will run only on the
> >> join
> >> points picked out
> >> by the pointcut in the abstract aspect.  the pointcut in the 
> subaspect
> >> does
> >> not override
> >> but hides the superaspect pointcut of the same name (indeed, I 
> thought
> >> we
> >> had an
> >> XLint warning for this.)
> >>  
> >> Normally the pointcut in the abstract aspect is itself abstract, for
> >> just
> >> this reason. 
> >> Some people use the convention of another  pointcut titled
> >> {name}_default to
> >>
> >> offer reusable pointcut for subaspects to consider.
> >>  
> >> Wes
> >>  
> >> ------------Original Message------------
> >> From: Thiago Bartolomei <thiagobart@xxxxxxxxx>
> >> To: aspectj-users@xxxxxxxxxxx
> >> Date: Fri, Oct-21-2005 3:54 AM
> >> Subject: Re: [aspectj-users] Overriding pointcuts
> >> Hi,
> >>
> >> try to append target to your pointcut:
> >>
> >> pointcut log(Fifo fifo) : Logging.log(fifo) || execution(*
> >> Fifo.Get(..)) &&
> >> target(fifo);
> >>
> >> I think the problem is that the compiler needs to know what to do 
> with
> >> your
> >> fifo variable in all cases . Without the target, the second part of 
> the
> >> "or"
> >> would have no context exposure..
> >>
> >> []s
> >> Thiago T. Bartolomei
> >> On 10/21/05, Sven Apel <apel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >> Hi,
> >>
> >> I have a problem with overriding and reusing pointcuts. I want to
> >> extend the
> >> set of join points captured by the "log" pointcut in the aspect
> >> "Logging":
> >>
> >> abstract public aspect Logging
> >> {
> >>         pointcut log(Fifo fifo) : execution(* Fifo.Put(..)) 
> &&
> >> target(fifo);
> >>
> >>         before(Fifo fifo) : log(fifo)
> >>         {
> >>                 System.out.println("---> Fifo method
> >> called");
> >>         }
> >> }
> >>
> >> For that I want to use a further aspect that inherits from 
> "Logging":
> >>
> >> public aspect ExtLogging extends Logging
> >> {
> >>         pointcut log(Fifo fifo) : Logging.log(fifo) ||
> >> execution(*
> >> Fifo.Get(..));
> >> }
> >>
> >> The above example does not work because ajc cannot bind "fifo"
> >> (inconsistent
> >> binding).
> >>
> >> The following example also does not work:
> >>
> >> public aspect ExtLogging extends Logging
> >> {
> >>         pointcut log() : Logging.log(Fifo) || execution(*
> >> Fifo.Get(..));
> >> }
> >>
> >> This is because "ExtLogging.log" must have the same signature than
> >> "Logging.log". Other variants that declare an argument list in
> >> "ExtLogging.log" but do not pass "fifo" to "Logging.log" also do not
> >> work
> >>
> >> Is there a possibility to override and reuse parent pointcuts that
> >> expect
> >> arguments? Without arguments the above example works!
> >>
> >> Thanks in advance
> >>
> >> Sven
> >>
> >> --
> >> Dipl.-Inf. Sven Apel
> >> Institute for Technical and Business Information Systems
> >> Otto-von-Guericke-University
> >> P.O. Box 4120, D-39016 Magdeburg, Germany
> >> Phone: ++49 (391) 67-11899, Fax: ++49 (391) 67-12020
> >> Room: 29/108
> >> E-Mail: apel@xxxxxxxxxxxxxxxxxxxxxxx
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> aspectj-users mailing list
> >> aspectj-users@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>
> >> _______________________________________________
> >> aspectj-users mailing list
> >> aspectj-users@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>
> >> _______________________________________________
> >> aspectj-users mailing list
> >> aspectj-users@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 



Back to the top