Logging aspect example

Ilias TsagklisNovember 11th, 2012Last Updated: November 11th, 2012

0 329 1 minute read

Once upon time I was writing a plugin for a closed-source LMS J2EE application having such dependencies that it wasn’t feasible to run it locally. During an API call, a method deep inside the application was failing but the exception didn’t contain enough information to track the cause of the problem. I therefore needed to change the method to log the value of its argument when it fails.

The AspectJ code is quite simple:

LoggingAspect.java

@Aspect
public class LoggingAspect {
  
   @Around("execution(private void TooQuiet3rdPartyClass.failingMethod(..))")
   public Object interceptAndLog(ProceedingJoinPoint invocation) throws Throwable {
 
try {
 
   return invocation.proceed();
 
} catch (Exception e) {
 
   Logger.getLogger("AspectJ").warning(
 
"THE INJECTED CODE SAYS: the method " +
 
invocation.getSignature().getName() + " failed for the input '" +
 
invocation.getArgs()[0] + "'. Original exception: " + e);
 
   throw e;
 
}
   }
}

Notes:

The aspect is a normal Java class with the @Aspect annotation, which is just a marker for AspectJ
The @Around annotation instructs AspectJ to execute the method instead of the one matched by the expression, i.e. instead of the failingMethod of the TooQuiet3rdPartyClass
The around advice method needs to be public, return an Object, and take a special AspectJ object carrying information about the invocation – ProceedingJoinPoint – as its argument and it may have an arbitrary name (Actually this is the minimal form of the signature, it could be more complex.)
We use the ProceedingJoinPoint to delegate the call to the original target (an instance of the TooQuiet3rdPartyClass) and, in the case of an exception, to get the argument’s value
I’ve used an @Around advice though @AfterThrowing would be simpler and more appropriate but this shows better the capabilities of AspectJ and can be nicely compared to the dynamic java proxy example above

Since I hadn’t control over the application’s environment, I couldn’t enable the load-time weaving and thus had to use AspectJ’s Ant task to weave the code at the build time, re-package the affected JAR and re-deploy it to the server.

Related Article: