Limitations of Spring AOP and Java Agent Solutions for the Diagnose Framework

Aspect‑Oriented Programming (AOP) is a powerful technique for modularizing cross‑cutting concerns in software development. This article examines the implementation of AOP on the Java platform, focusing on Spring AOP and its limitations when applied to the Diagnose logging framework used internally.

Spring AOP, which builds on CGLIB and JDK dynamic proxies, is widely used for logging, permission checks, and RPC interception. However, it suffers from three major constraints:

Only methods of Spring beans can be advised; non‑bean classes cannot be intercepted.

Static methods cannot be proxied because proxies rely on subclassing or interface implementation.

Advice is triggered only by external calls; internal calls via this.xxx() bypass the proxy.

The third limitation is illustrated with the following example:

@Component
public class A {
    @Diagnosed(name = "foo")
    public void foo() {
        bar();
        wof();
    }

    @Diagnosed(name = "wof")
    private void wof() {
        System.out.println("A.wof");
    }

    @Diagnosed(name = "bar")
    public void bar() {
        System.out.println("A.bar");
    }
}

@Component
public class B {
    @Resource
    private A a;

    public void invokeA() {
        a.foo();
    }
}

When A.foo() is invoked from bean B , only the advice on foo executes; the advice on wof and bar does not, because the internal calls are not routed through the proxy.

Spring AOP’s runtime nature prevents it from modifying the original class bytecode; it can only create a subclass or an interface implementation, which explains the above constraints.

To overcome these limitations, a Java Agent can be employed. A Java Agent runs at JVM startup and can transform class bytecode directly, eliminating the need for subclassing. The typical steps are:

Define a class with a static premain(String agentArgs, Instrumentation inst) method.

Create a META-INF/MANIFEST.MF that specifies the premain class.

Package the agent JAR (often with dependencies) and launch the application with -javaagent:/path/to/agent.jar=package.prefixes .

During transformation, the agent matches classes whose methods are annotated with @Diagnosed and injects a custom interceptor (e.g., SelfInvokeMethodInterceptor ) that delegates to the original Diagnose interceptor.

When integrating a Java Agent with Spring Boot, class‑loader issues arise because the agent runs in the AppClassLoader while the application runs in LaunchedURLClassLoader . To avoid ClassNotFoundException , the solution separates the agent into two modules:

diagnose-agent – contains only ByteBuddy and agent logic, no business dependencies.

diagnose-client – depends on Spring, logging, and other business libraries and is loaded by the application class loader.

By loading business classes via reflection from the agent, the agent remains independent of the application’s class path, and the AOP advice works for private and static methods as well as internal calls.

Finally, the article demonstrates the successful interception of private methods decryptBuyerId , getAndCheckOrder , and static method ResultDTO.fail , confirming that the Java Agent approach resolves the three Spring AOP limitations.