Declaring Advice

Advice is associated with a pointcut expression and runs before, after, or around method executions matched by the pointcut. The pointcut expression may be either an inline pointcut or a reference to a named pointcut.

Before Advice

You can declare before advice in an aspect by using the @Before annotation.

The following example uses an inline pointcut expression.

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class BeforeExample {

  @Before("execution(* com.xyz.dao.*.*(..))")
  public void doAccessCheck() {
    // ...
  }
}

If we use a named pointcut, we can rewrite the preceding example as follows:

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class BeforeExample {

  @Before("com.xyz.CommonPointcuts.dataAccessOperation()")
  public void doAccessCheck() {
    // ...
  }
}

After Returning Advice

After returning advice runs when a matched method execution returns normally. You can declare it by using the @AfterReturning annotation.

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.AfterReturning;

@Aspect
public class AfterReturningExample {

  @AfterReturning("execution(* com.xyz.dao.*.*(..))")
  public void doAccessCheck() {
    // ...
  }
}

You can have multiple advice declarations (and other members as well), all inside the same aspect. We show only a single advice declaration in these examples to focus the effect of each one.

Sometimes, you need access in the advice body to the actual value that was returned. You can use the form of @AfterReturning that binds the return value to get that access, as the following example shows:

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.AfterReturning;

@Aspect
public class AfterReturningExample {

  @AfterReturning(
    pointcut="execution(* com.xyz.dao.*.*(..))",
    returning="retVal")
  public void doAccessCheck(Object retVal) {
    // ...
  }
}

The name used in the returning attribute must correspond to the name of a parameter in the advice method. When a method execution returns, the return value is passed to the advice method as the corresponding argument value. A returning clause also restricts matching to only those method executions that return a value of the specified type (in this case, Object, which matches any return value).

Please note that it is not possible to return a totally different reference when using after returning advice.

After Throwing Advice

After throwing advice runs when a matched method execution exits by throwing an exception. You can declare it by using the @AfterThrowing annotation, as the following example shows:

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.AfterThrowing;

@Aspect
public class AfterThrowingExample {

  @AfterThrowing("execution(* com.xyz.dao.*.*(..))")
  public void doRecoveryActions() {
    // ...
  }
}

Often, you want the advice to run only when exceptions of a given type are thrown, and you also often need access to the thrown exception in the advice body. You can use the throwing attribute to both restrict matching (if desired — use Throwable as the exception type otherwise) and bind the thrown exception to an advice parameter. The following example shows how to do so:

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.AfterThrowing;

@Aspect
public class AfterThrowingExample {

  @AfterThrowing(
    pointcut="execution(* com.xyz.dao.*.*(..))",
    throwing="ex")
  public void doRecoveryActions(DataAccessException ex) {
    // ...
  }
}

The name used in the throwing attribute must correspond to the name of a parameter in the advice method. When a method execution exits by throwing an exception, the exception is passed to the advice method as the corresponding argument value. A throwing clause also restricts matching to only those method executions that throw an exception of the specified type (DataAccessException, in this case).

Note that @AfterThrowing does not indicate a general exception handling callback. Specifically, an @AfterThrowing advice method is only supposed to receive exceptions from the join point (user-declared target method) itself but not from an accompanying @After/@AfterReturning method.

After (Finally) Advice

After (finally) advice runs when a matched method execution exits. It is declared by using the @After annotation. After advice must be prepared to handle both normal and exception return conditions. It is typically used for releasing resources and similar purposes. The following example shows how to use after finally advice:

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.After;

@Aspect
public class AfterFinallyExample {

  @After("execution(* com.xyz.dao.*.*(..))")
  public void doReleaseLock() {
    // ...
  }
}

Note that @After advice in AspectJ is defined as "after finally advice", analogous to a finally block in a try-catch statement. It will be invoked for any outcome, normal return or exception thrown from the join point (user-declared target method), in contrast to @AfterReturning which only applies to successful normal returns.

Around Advice

The last kind of advice is around advice. Around advice runs "around" a matched method’s execution. It has the opportunity to do work both before and after the method runs and to determine when, how, and even if the method actually gets to run at all. Around advice is often used if you need to share state before and after a method execution in a thread-safe manner – for example, starting and stopping a timer.

Always use the least powerful form of advice that meets your requirements.

For example, do not use around advice if before advice is sufficient for your needs.

Around advice is declared by annotating a method with the @Around annotation. The method should declare Object as its return type, and the first parameter of the method must be of type ProceedingJoinPoint. Within the body of the advice method, you must invoke proceed() on the ProceedingJoinPoint in order for the underlying method to run. Invoking proceed() without arguments will result in the caller’s original arguments being supplied to the underlying method when it is invoked. For advanced use cases, there is an overloaded variant of the proceed() method which accepts an array of arguments (Object[]). The values in the array will be used as the arguments to the underlying method when it is invoked.

The behavior of proceed when called with an Object[] is a little different than the behavior of proceed for around advice compiled by the AspectJ compiler. For around advice written using the traditional AspectJ language, the number of arguments passed to proceed must match the number of arguments passed to the around advice (not the number of arguments taken by the underlying join point), and the value passed to proceed in a given argument position supplants the original value at the join point for the entity the value was bound to (do not worry if this does not make sense right now).

The approach taken by Infra is simpler and a better match to its proxy-based, execution-only semantics. You only need to be aware of this difference if you compile @AspectJ aspects written for Infra and use proceed with arguments with the AspectJ compiler and weaver. There is a way to write such aspects that is 100% compatible across both Infra AOP and AspectJ, and this is discussed in the following section on advice parameters.

The value returned by the around advice is the return value seen by the caller of the method. For example, a simple caching aspect could return a value from a cache if it has one or invoke proceed() (and return that value) if it does not. Note that proceed may be invoked once, many times, or not at all within the body of the around advice. All of these are legal.

If you declare the return type of your around advice method as void, null will always be returned to the caller, effectively ignoring the result of any invocation of proceed(). It is therefore recommended that an around advice method declare a return type of Object. The advice method should typically return the value returned from an invocation of proceed(), even if the underlying method has a void return type. However, the advice may optionally return a cached value, a wrapped value, or some other value depending on the use case.

The following example shows how to use around advice:

Java

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.ProceedingJoinPoint;

@Aspect
public class AroundExample {

  @Around("execution(* com.xyz..service.*.*(..))")
  public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable {
    // start stopwatch
    Object retVal = pjp.proceed();
    // stop stopwatch
    return retVal;
  }
}

Advice Parameters

Infra offers fully typed advice, meaning that you declare the parameters you need in the advice signature (as we saw earlier for the returning and throwing examples) rather than work with Object[] arrays all the time. We see how to make argument and other contextual values available to the advice body later in this section. First, we take a look at how to write generic advice that can find out about the method the advice is currently advising.

Access to the Current `JoinPoint`

Any advice method may declare, as its first parameter, a parameter of type org.aspectj.lang.JoinPoint. Note that around advice is required to declare a first parameter of type ProceedingJoinPoint, which is a subclass of JoinPoint.

The JoinPoint interface provides a number of useful methods:

getArgs(): Returns the method arguments.
getThis(): Returns the proxy object.
getTarget(): Returns the target object.
getSignature(): Returns a description of the method that is being advised.
toString(): Prints a useful description of the method being advised.

See the javadoc for more detail.

Passing Parameters to Advice

We have already seen how to bind the returned value or exception value (using after returning and after throwing advice). To make argument values available to the advice body, you can use the binding form of args. If you use a parameter name in place of a type name in an args expression, the value of the corresponding argument is passed as the parameter value when the advice is invoked. An example should make this clearer. Suppose you want to advise the execution of DAO operations that take an Account object as the first parameter, and you need access to the account in the advice body. You could write the following:

Java

@Before("execution(* com.xyz.dao.*.*(..)) && args(account,..)")
public void validateAccount(Account account) {
  // ...
}

The args(account,..) part of the pointcut expression serves two purposes. First, it restricts matching to only those method executions where the method takes at least one parameter, and the argument passed to that parameter is an instance of Account. Second, it makes the actual Account object available to the advice through the account parameter.

Another way of writing this is to declare a pointcut that "provides" the Account object value when it matches a join point, and then refer to the named pointcut from the advice. This would look as follows:

Java

@Pointcut("execution(* com.xyz.dao.*.*(..)) && args(account,..)")
private void accountDataAccessOperation(Account account) {}

@Before("accountDataAccessOperation(account)")
public void validateAccount(Account account) {
  // ...
}

See the AspectJ programming guide for more details.

The proxy object (this), target object (target), and annotations (@within, @target, @annotation, and @args) can all be bound in a similar fashion. The next set of examples shows how to match the execution of methods annotated with an @Auditable annotation and extract the audit code:

The following shows the definition of the @Auditable annotation:

Java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Auditable {
  AuditCode value();
}

The following shows the advice that matches the execution of @Auditable methods:

Java

@Before("com.xyz.Pointcuts.publicMethod() && @annotation(auditable)") (1)
public void audit(Auditable auditable) {
  AuditCode code = auditable.value();
  // ...
}

1	References the `publicMethod` named pointcut defined in Combining Pointcut Expressions.

Advice Parameters and Generics

Infra AOP can handle generics used in class declarations and method parameters. Suppose you have a generic type like the following:

Java

public interface Sample<T> {
  void sampleGenericMethod(T param);
  void sampleGenericCollectionMethod(Collection<T> param);
}

You can restrict interception of method types to certain parameter types by tying the advice parameter to the parameter type for which you want to intercept the method:

Java

@Before("execution(* ..Sample+.sampleGenericMethod(*)) && args(param)")
public void beforeSampleMethod(MyType param) {
  // Advice implementation
}

This approach does not work for generic collections. So you cannot define a pointcut as follows:

Java

@Before("execution(* ..Sample+.sampleGenericCollectionMethod(*)) && args(param)")
public void beforeSampleMethod(Collection<MyType> param) {
  // Advice implementation
}

To make this work, we would have to inspect every element of the collection, which is not reasonable, as we also cannot decide how to treat null values in general. To achieve something similar to this, you have to type the parameter to Collection<?> and manually check the type of the elements.

Determining Argument Names

Parameter binding in advice invocations relies on matching the names used in pointcut expressions to the parameter names declared in advice and pointcut method signatures.

This section uses the terms argument and parameter interchangeably, since AspectJ APIs refer to parameter names as argument names.

Infra AOP uses the following ParameterNameDiscoverer implementations to determine parameter names. Each discoverer will be given a chance to discover parameter names, and the first successful discoverer wins. If none of the registered discoverers is capable of determining parameter names, an exception will be thrown.

AspectJAnnotationParameterNameDiscoverer: Uses parameter names that have been explicitly specified by the user via the argNames attribute in the corresponding advice or pointcut annotation. See Explicit Argument Names for details.
KotlinReflectionParameterNameDiscoverer: Uses Kotlin reflection APIs to determine parameter names. This discoverer is only used if such APIs are present on the classpath.
StandardReflectionParameterNameDiscoverer: Uses the standard java.lang.reflect.Parameter API to determine parameter names. Requires that code be compiled with the -parameters flag for javac. Recommended approach on Java 8+.
AspectJAdviceParameterNameDiscoverer: Deduces parameter names from the pointcut expression, returning, and throwing clauses. See the javadoc for details on the algorithm used.

Explicit Argument Names

@AspectJ advice and pointcut annotations have an optional argNames attribute that you can use to specify the argument names of the annotated method.

If an @AspectJ aspect has been compiled by the AspectJ compiler (ajc) even without debug information, you do not need to add the argNames attribute, since the compiler retains the needed information.

Similarly, if an @AspectJ aspect has been compiled with javac using the -parameters flag, you do not need to add the argNames attribute, since the compiler retains the needed information.

The following example shows how to use the argNames attribute:

Java

@Before(value = "com.xyz.Pointcuts.publicMethod() && target(bean) && @annotation(auditable)", (1)
  argNames = "bean,auditable") (2)
public void audit(Object bean, Auditable auditable) {
  AuditCode code = auditable.value();
  // ... use code and bean
}

1	References the `publicMethod` named pointcut defined in Combining Pointcut Expressions.
2	Declares `bean` and `auditable` as the argument names.

If the first parameter is of type JoinPoint, ProceedingJoinPoint, or JoinPoint.StaticPart, you can omit the name of the parameter from the value of the argNames attribute. For example, if you modify the preceding advice to receive the join point object, the argNames attribute does not need to include it:

Java

@Before(value = "com.xyz.Pointcuts.publicMethod() && target(bean) && @annotation(auditable)", (1)
  argNames = "bean,auditable") (2)
public void audit(JoinPoint jp, Object bean, Auditable auditable) {
  AuditCode code = auditable.value();
  // ... use code, bean, and jp
}

1	References the `publicMethod` named pointcut defined in Combining Pointcut Expressions.
2	Declares `bean` and `auditable` as the argument names.

The special treatment given to the first parameter of type JoinPoint, ProceedingJoinPoint, or JoinPoint.StaticPart is particularly convenient for advice methods that do not collect any other join point context. In such situations, you may omit the argNames attribute. For example, the following advice does not need to declare the argNames attribute:

Java

@Before("com.xyz.Pointcuts.publicMethod()") (1)
public void audit(JoinPoint jp) {
  // ... use jp
}

1	References the `publicMethod` named pointcut defined in Combining Pointcut Expressions.

Proceeding with Arguments

We remarked earlier that we would describe how to write a proceed call with arguments that works consistently across Infra AOP and AspectJ. The solution is to ensure that the advice signature binds each of the method parameters in order. The following example shows how to do so:

Java

@Around("execution(List<Account> find*(..)) && " +
    "com.xyz.CommonPointcuts.inDataAccessLayer() && " +
    "args(accountHolderNamePattern)") (1)
public Object preProcessQueryPattern(ProceedingJoinPoint pjp,
    String accountHolderNamePattern) throws Throwable {
  String newPattern = preProcess(accountHolderNamePattern);
  return pjp.proceed(new Object[] {newPattern});
}

1	References the `inDataAccessLayer` named pointcut defined in Sharing Named Pointcut Definitions.

In many cases, you do this binding anyway (as in the preceding example).

Advice Ordering

What happens when multiple pieces of advice all want to run at the same join point? Infra AOP follows the same precedence rules as AspectJ to determine the order of advice execution. The highest precedence advice runs first "on the way in" (so, given two pieces of before advice, the one with highest precedence runs first). "On the way out" from a join point, the highest precedence advice runs last (so, given two pieces of after advice, the one with the highest precedence will run second).

When two pieces of advice defined in different aspects both need to run at the same join point, unless you specify otherwise, the order of execution is undefined. You can control the order of execution by specifying precedence. This is done in the normal Infra way by either implementing the cn.taketoday.core.Ordered interface in the aspect class or annotating it with the @Order annotation. Given two aspects, the aspect returning the lower value from Ordered.getOrder() (or the annotation value) has the higher precedence.

Each of the distinct advice types of a particular aspect is conceptually meant to apply to the join point directly. As a consequence, an @AfterThrowing advice method is not supposed to receive an exception from an accompanying @After/@AfterReturning method.

advice methods defined in the same @Aspect class that need to run at the same join point are assigned precedence based on their advice type in the following order, from highest to lowest precedence: @Around, @Before, @After, @AfterReturning, @AfterThrowing. Note, however, that an @After advice method will effectively be invoked after any @AfterReturning or @AfterThrowing advice methods in the same aspect, following AspectJ’s "after finally advice" semantics for @After.

When two pieces of the same type of advice (for example, two @After advice methods) defined in the same @Aspect class both need to run at the same join point, the ordering is undefined (since there is no way to retrieve the source code declaration order through reflection for javac-compiled classes). Consider collapsing such advice methods into one advice method per join point in each @Aspect class or refactor the pieces of advice into separate @Aspect classes that you can order at the aspect level via Ordered or @Order.