Spring Boot AOP (Aspect-Oriented Programming)

Work through this checklist:

1. The AOP starter is missing from your dependencies.
2. @Component is missing on the aspect, so Spring never creates it.
3. The pointcut does not match: a typo in the package name, or . instead of .. for sub-packages.
4. The annotation in @annotation(...) is not fully qualified and is in a different package from the aspect.
5. The method is called from the same class, so it skips the proxy.
6. The method is private, final or static, or the object is not a Spring bean.

A quick test: temporarily use a very broad pointcut, such as within(com.javabytechie..*), and see whether the advice runs at all.

Only slightly. Each advised call passes through the proxy and the advice, which costs a tiny amount of time, usually far less than a database query or HTTP call.

It becomes noticeable only when:

• The pointcut is very broad and matches small methods that are called millions of times.
• The advice itself does slow work, such as writing to a database on every call.

Keep pointcuts targeted, keep advice fast, and measure if in doubt.

Because you are looking at the proxy, not your original class. When an aspect applies to a bean, Spring creates a subclass at runtime, with a name such as OrderService$$SpringCGLIB$$0, and injects it in place of the original.

This is normal and harmless. It also explains why getClass() on an injected bean may not return exactly your class. Use AopUtils.getTargetClass(bean) if you need the original class.

Use filters and interceptors for concerns about HTTP requests, and aspects for concerns about method calls, especially in the service layer, where no HTTP request may be involved at all.

Not with Spring AOP. Entities are created by Hibernate, not by Spring, so Spring never wraps them in a proxy.

For entity events, use JPA’s own callbacks instead:

@Entity
@EntityListeners(AuditListener.class)
public class Order {

    @PrePersist
    void beforeInsert() {
        this.createdAt = Instant.now();
    }
}

Annotations such as @PrePersist, @PreUpdate and @PostLoad, or an entity listener class, cover most needs. Full AspectJ weaving could advise entities, but it is rarely worth the setup.

Cast the signature to MethodSignature:

@Before("@annotation(com.javabytechie.shop.aop.Audited)")
public void describe(JoinPoint joinPoint) {
    MethodSignature signature = (MethodSignature) joinPoint.getSignature();

    String className = signature.getDeclaringType().getSimpleName();
    String methodName = signature.getName();
    String[] parameterNames = signature.getParameterNames();
    Object[] values = joinPoint.getArgs();

    for (int i = 0; i < values.length; i++) {
        log.info("{}.{}: {} = {}", className, methodName, parameterNames[i], values[i]);
    }
}

signature.getMethod() also gives the full java.lang.reflect.Method, for example to read other annotations on it.

Yes, but only @Around advice can. Pass new arguments to proceed(), and return whatever result you want:

@Around("@annotation(com.javabytechie.shop.aop.TrimStrings)")
public Object trimArguments(ProceedingJoinPoint joinPoint) throws Throwable {
    Object[] args = joinPoint.getArgs();
    for (int i = 0; i < args.length; i++) {
        if (args[i] instanceof String text) {
            args[i] = text.trim();
        }
    }
    return joinPoint.proceed(args);   // call the method with the cleaned arguments
}

Use this sparingly. Changing data invisibly can surprise other developers, who see one value at the call site and a different one inside the method.

An aspect is a normal bean, so the usual conditions work:

@Aspect
@Component
@Profile("dev")                     // only in the dev profile
public class DetailedLoggingAspect { ... }

@Aspect
@Component
@ConditionalOnProperty(name = "shop.audit.enabled", havingValue = "true")
public class AuditAspect { ... }

If the bean is not created, the aspect simply does not exist, and the advised methods run without it.

The exception reaches the caller, just as if the method itself had thrown it:

• An exception in @Before advice means the method never runs.
• An exception in @AfterReturning advice turns a successful call into a failure for the caller.
• Inside a transaction, it can cause a rollback.

For non-essential concerns, such as logging or metrics, catch exceptions inside the advice, so a logging problem never breaks a business operation.

It depends on the order. @Transactional is itself an aspect, with the lowest priority by default, so it sits closest to your method. A custom aspect with a normal @Order value therefore runs outside the transaction:

YourAspect (Order 1) ─▶ Transaction advice ─▶ your method

This matters, for example, for a retry aspect: running outside the transaction, each retry starts a fresh transaction, which is usually what you want. If your aspect must run inside the transaction, give the transaction advice a higher priority with @EnableTransactionManagement(order = ...).

Never log every argument blindly. Mark sensitive parameters and mask them in the aspect:

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface Sensitive { }

// In the aspect
MethodSignature signature = (MethodSignature) joinPoint.getSignature();
Annotation[][] annotations = signature.getMethod().getParameterAnnotations();
Object[] args = joinPoint.getArgs();
for (int i = 0; i < args.length; i++) {
    boolean sensitive = Arrays.stream(annotations[i]).anyMatch(a -> a instanceof Sensitive);
    log.info("arg {} = {}", i, sensitive ? "****" : args[i]);
}

public void changePassword(String username, @Sensitive String newPassword) { ... }

Also be careful with whole objects: a DTO’s toString() may include sensitive fields, so exclude them there too.

Yes, when the call happens during a web request:

ServletRequestAttributes attributes =
        (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
if (attributes != null) {
    HttpServletRequest request = attributes.getRequest();
    log.info("{} {} from {}", request.getMethod(), request.getRequestURI(), request.getRemoteAddr());
}

Always check for null: the same service method may also be called from a scheduled job or a message listener, where there is no request. If the aspect is really about HTTP requests, a filter or interceptor is usually the better tool.

Both add behavior around existing code without changing it. The difference is scale and wiring:

• A decorator is a class you write by hand that wraps one specific interface and delegates to it. It is explicit and easy to follow, but you write one per interface.
• An aspect applies to many classes at once, chosen by a pointcut, and Spring does the wrapping for you.

For behavior on one or two types, a decorator is often clearer. For the same concern across dozens of classes, an aspect avoids a lot of repetitive code.

There is no fixed number, but every aspect adds behavior that is not visible in the code it affects. When a method behaves in surprising ways and the reason is hidden in an aspect, debugging becomes slow.

Good signs that you are using AOP well:

• Each aspect handles one clear, technical concern.
• Annotations such as @Audited make it visible which methods are affected.
• The team can list every aspect in the project from memory.

If an aspect starts to contain business rules, move that logic back into the service code.

Yes. Micrometer, which Spring Boot uses for metrics, provides annotation-based aspects:

@Timed(value = "orders.place", description = "Time to place an order")
public Order placeOrder(OrderRequest request) { ... }

@Observed(name = "reports.build")   // timer metrics and a tracing span together
public Report buildMonthlyReport(YearMonth month) { ... }

These need the matching aspect beans, TimedAspect or ObservedAspect, which recent Spring Boot versions can register for you. The results appear in Actuator metrics and monitoring tools, without any custom timing code.

Weaving is the step that combines aspects with your code. It can happen at three moments:

Runtime weaving needs no special build steps, which is why Spring AOP is so easy to start with, but it is also why it only works through proxies.

• @annotation(X) matches methods that themselves carry annotation X.
• @within(X) matches every method of classes annotated with X.

@Audited                         // @within(Audited) matches every method here
public class PaymentService {

    @Audited                     // @annotation(Audited) matches only this one
    public void refund(Long id) { ... }

    public void charge(Long id) { ... }
}

Combine them with || to support both styles: annotate a whole class, or just selected methods.

The advice runs only when the call reaches the advised method through the proxy. Calls from a static or private method in the same class go directly to the object, so no advice runs, just as with any self-invocation.

Calls from a different bean always go through the proxy, regardless of whether the calling method there is private or static. The rule is about who holds the reference: the proxy or the raw object.

An introduction makes existing beans implement an extra interface, with an implementation supplied by the aspect:

@Aspect
@Component
public class UsageTrackingIntroduction {

    @DeclareParents(value = "com.javabytechie.shop.service.*+",
                    defaultImpl = DefaultUsageTracked.class)
    public static UsageTracked mixin;
}

Every matching bean can then be cast to UsageTracked. Introductions are rarely used in everyday applications, because ordinary interfaces and composition are usually clearer, but they are useful to know when reading framework code.

Very much so, often without you noticing. @Transactional, @Cacheable, @Async, @Retryable, method security with @PreAuthorize, and Micrometer’s @Timed and @Observed are all built on AOP.

Understanding how aspects and proxies work explains the most common surprises with all of these features, such as self-invocation and private methods, even if you rarely write an aspect yourself.