Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
>

Back to the top