Hi,
*
- what changes are needed to my pointcuts definitions so I'll be able to
avoid the recursive calls?
*You have a couple of choices:
1) Exclude the toString() methods:
pointcut flowCut(): (call(* com.mycomp..*(..)) ||
call(com.mycomp..*.new(..))) && !call(* toString(..));
2) Avoid invoking the advice if you are already in the control flow of the
advice
pointcut flowCut(): (call(* com.mycomp..*(..)) ||
call(com.mycomp..*.new(..))) && !cflow(adviceexecution());
This second pointcut says I am interested in calls to methods in com.mycomp
unless they occur after I've already entered the advice. This means any
toString()s that get called during advice execution will not call back into
the advice and you avoid the recursion.
- *is there a better way to know who is the calling object?*
If you don't use thisJoinPoint then the alternative is to bind it:
pointcut flowCut(Object o): (call(* com.mycomp..*(..)) ||
call(com.mycomp..*.new(..))) && this(o);
pointcut notAspect(): !within(MyAspect);
Object around(Object caller): notAspect() && flowCut(caller) {
Then 'caller' is bound to the calling object in the advice. However - this
will not work for method calls from a static context (as discussed on the
list a little while ago) - so you will need pairs of pointcuts - one for
static, one for non-static and two advice (these advice could delegate to a
method and so there is no need to duplicate the advice body).
pointcut notAspect(): !within(MyAspect);
pointcut flowCutStatic(): (call(* com.mycomp..*(..)) ||
call(com.mycomp..*.new(..))) && !this(Object); // !this(Object) means 'am i
in a static context?'
pointcut flowCutNonStatic(Object o): (call(* com.mycomp..*(..)) ||
call(com.mycomp..*.new(..))) && this(o);
Object around(Object caller): notAspect() && flowCut(caller) {
doSomething(caller);
}
Object around(): notAspect() && flowCut() {
doSomething(null);
}
Andy.
2009/1/27 NewWay <[email protected]>
> Hello all,
>
> this is going to be a long one, so please bear with me. I can assure you
> that I've searched the net for a solution before writing this post
> ------------------------------
>
> I'm using aspectj to follow the excecution of my flow, so this is how my
> advice looks like:
>
> public aspect MyAspect{
>
> pointcut flowCut(): (call(* com.mycomp..*(..)) ||
> call(com.mycomp..*.new(..)));
>
> pointcut notAspect(): !within(MyAspect);
>
> Object around(): notAspect() && flowCut(){
>
> Date startDate = new Date(System.currentTimeMillis());
> System.out.println("enter " + thisJoinPoint.getSignature()
> + " caller=" + thisJoinPoint.getThis() + "
> calling method="
> +
> thisEnclosingJoinPointStaticPart.getSignature());
>
> Object result = proceed();
>
> Date endDate = new Date(System.currentTimeMillis());
> System.out.println("exit " + thisJoinPoint.getSignature() + ";
> caller="
> + thisJoinPoint.getThis() + "; calling method="
> +
> thisEnclosingJoinPointStaticPart.getSignature()
> + "; result: " + result + "; elapsed "
> + (endDate.getTime() - startDate.getTime()) + "
> millisecs");
>
> return result;
> }
> }
>
> I'm using *
>
> "caller="+ thisJoinPoint.getThis()
>
> * because i want to know the specific instance of the caller. now my
> problem is that if one of my classes, under com.mycomp..* overrides the *
> toString* method, i don't get the instance number and the toString is
> activated, resulting in stack overflow.
>
> I haven't managed to figure yet how the *hashCode* method is activated,
> but after I commented out all the *toSring* implementations, I started
> getting stack over flows that narroed down again to string builder and
> toString calls
> ------------------------------
> *
>
> So my question is
>
> - what changes are needed to my pointcuts definitions so I'll be able
> to avoid the recursive calls?
> - is there a better way to know who is the calling object?
>
> *
> ------------------------------
> View this message in context: Avoid toString and hashCode exec/call being
> adviced<http://www.nabble.com/Avoid-toString-and-hashCode-exec-call-being-adviced-tp21688532p21688532.html>
> Sent from the AspectJ - users mailing list
> archive<http://www.nabble.com/AspectJ---users-f2219.html>at Nabble.com.
>
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
