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