Spring AOP Proxy Fails with BeanPostProcessor and FactoryBean Dependencies

When working with Spring Framework, one of the strengths developers often rely on is Spring AOP (Aspect-Oriented Programming). It helps us effectively implement cross-cutting concerns such as logging, transaction management, and security. However, sometimes strange issues pop up—especially when BeanPostProcessors and FactoryBeans with additional dependencies enter the picture.

One puzzling situation many developers encounter occurs when attempting to proxy beans, such as a simple HelloService, using Spring AOP. Specifically, if you implement a custom BeanPostProcessor that depends on another bean (GoodByeService in this case) and simultaneously involve a FactoryBean for creating certain beans, you may find your proxies mysteriously missing. Instead of getting a fully proxied HelloService, you’re left with a plain Java object that has none of Spring AOP’s enhanced capabilities.

Expected Behavior of Proxied Beans

Ideally, when properly configured, the HelloService bean should be wrapped in a Spring proxy (either JDK-based or CGLIB-based). You can confirm a successful proxy creation using Spring’s AOP utility methods:

• AopUtils.isAopProxy(helloService) should return true.
• Either AopUtils.isJdkDynamicProxy(helloService) or AopUtils.isCglibProxy(helloService) should return true.

Additionally, the aspect methods defined via annotations like @AfterReturning should execute after invoking a corresponding method like sayHello().

Actual Observed Behavior

Unfortunately, in certain configurations involving BeanPostProcessors with dependencies, the proxy simply doesn’t get created. When you run your checks, the results are unexpected:

• AopUtils.isAopProxy(helloService) returns false.
• AopUtils.isJdkDynamicProxy(helloService) and AopUtils.isCglibProxy(helloService) both return false.

Moreover, the aspects intended to run upon invoking methods in HelloService never trigger. Your carefully defined @AfterReturning advice silently fails to execute.

Minimal Reproducible Example

Let’s go step-by-step to reproduce this issue clearly and consistently. The following minimal example illustrates this scenario clearly:

POM File (Maven Configuration)

Ensure you have Spring’s AOP module:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>5.3.25</version>
</dependency>
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
    <version>1.9.20</version>
</dependency>

Configuration Class

A basic Java configuration might look like this:

@Configuration
@ComponentScan("com.example")
@EnableAspectJAutoProxy
public class AppConfig {

    @Bean
    public MyFactoryBean myFactoryBean() {
        return new MyFactoryBean();
    }

    @Bean
    public MyPostProcessor myPostProcessor(GoodByeService goodByeService) {
        return new MyPostProcessor(goodByeService);
    }
}

Custom BeanPostProcessor

public class MyPostProcessor implements BeanPostProcessor {
    private final GoodByeService goodByeService;

    public MyPostProcessor(GoodByeService goodByeService) {
        this.goodByeService = goodByeService;
    }

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        return bean;
    }
}

Service Classes

HelloService.java:

@Component
public class HelloService {
    public void sayHello() {
        System.out.println("Hello!");
    }
}

GoodByeService.java:

@Component
public class GoodByeService {
    public void sayGoodbye() {
        System.out.println("Goodbye!");
    }
}

FactoryBean Implementation

public class MyFactoryBean implements FactoryBean<HelloService> {

    @Autowired
    private HelloService helloService; // This dependency triggers the issue

    @Override
    public HelloService getObject() {
        return helloService;
    }

    @Override
    public Class<?> getObjectType() {
        return HelloService.class;
    }
}

Aspect Definition

@Aspect
@Component
public class MyAspect {

    @AfterReturning("execution(* com.example.HelloService.sayHello(..))")
    public void afterAdvice() {
        System.out.println("After HelloService method invocation.");
    }
}

Main Application to Test

public class MainApplication {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context =
            new AnnotationConfigApplicationContext(AppConfig.class);

        HelloService helloService = context.getBean(HelloService.class);

        System.out.println("Is AOP proxy: " + AopUtils.isAopProxy(helloService));
        helloService.sayHello();

        context.close();
    }
}

Expected Console Output (But Not Observed)

Is AOP proxy: true
Hello!
After HelloService method invocation.

Analysis and Workaround Solutions

Upon analyzing, the culprit is typically related to bean initialization order, cyclic dependencies, and proxy creation timing in Spring’s bean lifecycle.

To solve this issue effectively, you have two reliable options:

1. Annotate the dependency in MyFactoryBean with @Lazy:

@Autowired
@Lazy
private HelloService helloService;

This ensures that the bean is injected only after initial proxy creation, preventing early dependency resolution.

2. Add proper generic type declarations to your FactoryBean, clarifying bean types explicitly.

This helps Spring correctly identify and proxy beans at the right time, avoiding unexpected initialization sequences.

Frequently Asked Question

Why does the presence of a BeanPostProcessor with dependencies interfere with AOP proxies?

This interference isn’t exactly a “bug” in the Spring Framework itself. Rather, it’s due to careful yet complex bean lifecycle and initialization rules. When a BeanPostProcessor depends on other beans, Spring may instantiate dependencies prematurely to satisfy injection points, effectively defeating the intended proxy wrappers around those beans.

Therefore, explicitly marking dependencies as lazy, or reorganizing bean creation order via clear generic declarations, is usually necessary to avoid such cyclical initialization traps.

For additional insights, check this detailed discussion on a similar Stack Overflow thread.

Additional Context and Further Clarification

Bean initialization order and proxy generation timings, detailed by official Spring documentation, clarify such scenarios. Proper comprehension of these concepts helps avoid similar pitfalls when combining tools like BeanPostProcessors, FactoryBeans, and AOP.

Have you experienced similar bean configuration and AOP proxying issues? Let me know your challenges or insights in the comments below!