| RE: [aspectj-users] why this cflow put counters in aspect itself? |
I misunderstood cflow; catching calls could be done without cflow:
pointcut singleStep(): !within(mypackage..*) && call(* *(..))
Thanks for the help.
From: "Wes" <wes@xxxxxxxxxxxxxx>
Reply-To: wes@xxxxxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] why this cflow put counters in aspect itself?
Date: Thu, 22 Jun 2006 10:51:17 -0700
>In this pointcut
>
> > > pointcut singleStep(): !within(mypackage..*) && cflow(call(*
> > > *(..))) && !execution(* *(..));
>
>there is almost no restriction on the triggering join point, so ajc
>can't prove to itself that the cflow will only be true at certain join
>points. So ajc has to set up the program to check whether singleStep()
>matches at every join point that might be in the control flow of a method
>execution or call. This can include join points in the aspect itself;
>e.g., advice bodies are in the control flow of the join points they advise.
>
>One of the things that can distinguish implementations of AspectJ is the
>degree to which they do static checking to prove that a given cflow will
>or won't match. It's perfectly legal for an implementation to check a
>cflow at every single join point in the program; it's just not efficient.
>So it's possible that what you see in the .class files will change with
>other AspectJ implementations or even between releases of Eclipse AspectJ.
>That's one of the reasons we strongly discourage people from decompiling
>the output in order to understand the language semantics. It's useful
>to decompile to track down bugs (e.g., performance issues when using
>cflow), but often you get results quicker by playing with the pointcuts
>to reduce the join points that might be matched.
>
>Wes
>
> > ------------Original Message------------
> > From: "Eric Bodden" <eric.bodden@xxxxxxxxxxxxxx>
> > To: aspectj-users@xxxxxxxxxxx
> > Date: Thu, Jun-22-2006 3:42 AM
> > Subject: RE: [aspectj-users] why this cflow put counters in aspect itself?
> >
> > Well, by stating !within(mypackage..*) you state that the joinpoint you
> > are interested in is not in your aspect package. This however must not
> > have any implications on the cflow pointcut and its update-shadow. If
> > you want to restrict this, you can change it to:
> >
> > cflow(!within(mypackage..*) && call(* *(..)))
> >
> > Eric
> >
> > > -----Original Message-----
> > > From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-
> > > bounces@xxxxxxxxxxx] On Behalf Of Gu Dake
> > > Sent: Wednesday, June 21, 2006 8:45 PM
> > > To: aspectj-users@xxxxxxxxxxx
> > > Subject: [aspectj-users] why this cflow put counters in aspect
> > itself?
> > >
> > > package mypackage;
> > >
> > > aspect MyAspect {
> > >
> > > pointcut singleStep(): !within(mypackage..*) && cflow(call(*
> > > *(..))) && !execution(* *(..));
> > >
> > > before(): singleStep() {
> > > System.out.println(thisJoinPointStaticPart);
> > > }
> > > }
> > >
> > > This aspect works fine at runtime. But when I opened the
> > > MyAspect.class in decompile tool, I saw some instrumented
> > > ajc$cflowCounter$0.inc() around my println()
> > >
> > >
> >
> > _______________________________________________
> > 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