This is something like what Matthew means, to replace the log.trace(..)
calls with calls from the aspect.
public aspect Trace { // warning: untested and subject to performance
mods
public boolean tracing; // ignoring how set for now
pointcut trace() : execution(* com.company..*.*(..))
&&
!cflow(adviceexecution(*) && within(Trace))
Object around() : traced() && if(tracing) {
trace(thisJoinPoint); } // new trace calls
public void trace(JoinPoint jp) { ... }
// skip old code when prototyping
// when complete, remove them to avoid parameter evaluation
void around() : call(void Log.trace(..)) {}
}
------------Original Message------------
From: Matthew Webster <matthew_webster@xxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Wed, Aug-9-2006 8:38 AM
Subject: Re: [aspectj-users] Logging guards and around
advice Ken,
It would seem that rather than replace your existing
tracing mechanism you are in fact trying to wrap it to improve its
performance. It has already been pointed out that this does not work because
AspectJ only considers a call join point to be the invocation itself and not
any parameter preamble. Also such a use of around advice is likely to negate
any potential performance gain from avoiding String concatenation. If you
really a high-performing AOP tracing infrastructure will have to replace the
existing implementation. The good news is you don't have to do it all at once;
try it one component at a time.
Matthew Webster AOSD Project Java Technology Centre, MP146 IBM
Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196
2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @
IBMGB,
matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/
"Carroll, Ken"
<Ken.Carroll@xxxxxxx> Sent by: aspectj-users-bounces@xxxxxxxxxxx
09/08/2006 13:29
Please respond
to aspectj-users@xxxxxxxxxxx |
|
To
| <aspectj-users@xxxxxxxxxxx>
|
cc
|
|
Subject
| [aspectj-users] Logging guards
and around advice |
|
We are seeking to use AspectJ to replace a proprietary mechanism
for tracing. The current tracing mechanism uses a code generation
approach (from xml configuration) that enables us to avoid evaluation
of parameters to the trace method. Essentially
log.trace("a" + b +
c.toString() + d.getBuffer())
would not have the string operations
executed should the logging level that currently applies not have tracing
on. This is a performance targeted design feature. We would like to get
away from the proprietary mechanism by using an around advice and a call
pointcut (combined with cflow to prevent recursion etc). However, thus far
we can see from decompiled code that the only thing we have control over is
the invocation of the trace method:
public aspect LoggingGuard
{ /** * Avoid recursion into the aspect and
* into toString calls, which may lead to infinite recursion
* and StackOverflowError exceptions */
protected pointcut traceMethods() : (
!cflow(execution(String *.toString()))
&&
!cflow(within(LoggingGuard))
&& call(void com.fidelity.Log.trace (..)));
Object
around() : traceMethods() { Log log =
((Log)(thisJoinPoint.getTarget())); if(log.isTraceEnabled()){
return proceed(); } else { return
null; } } } //end LoggingGuard
public class
LoggingGuardTest {
public static void main(String[]
args) {
Log log = new Log();
//if string is initialized, we should see System.err from
the myMethod() call
log.trace("Hello "+
myMethod());
}
private
static String myMethod(){
System.err.println("myMethod called!");
return "myMethod";
}
}
public static
void main(String args[])
{
Log log = new
Log();
String s = "Hello " + myMethod();
Log log1 = log;
JoinPoint joinpoint =
Factory.makeJP(ajc$tjp_0, null, log1, s);
if(!LoggingGuard.ajc$cflowCounter$0.isValid()
&& !LoggingGuard.ajc$cflowCounter$1.isValid())
trace_aroundBody1$advice(log1, s,
joinpoint, LoggingGuard.aspectOf(), null, joinpoint);
else
trace_aroundBody0(log1, s,
joinpoint);
}
As you can see the side-effect operations inside
the argument list to the trace method are all executed and only then does
the AJ joinpoint checking kick in.
Is there an advice, pointcut
_expression_ or anything else in AspectJ which would achieve what we need
here -- one which would essentially wrap the whole of the log.trace()
rather than just the trace method
call itself.
Thanks,
Ken
_______________________________________________ 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
|