-
Notifications
You must be signed in to change notification settings - Fork 645
Description
In what version(s) of Spring AMQP are you seeing this issue?
2.4.15
Describe the bug
The RabbitAdmin.initialize() method calls:
applicationContext.getBeansOfType(Declarable.class, false, true);
The third parameter allowEagerInit = true causes Spring to eagerly instantiate all FactoryBean instances in the application context — even those marked with lazy-init="true" — in order to determine their types.
This breaks lazy initialization semantics for beans such as:
MapperFactoryBean (from MyBatis-Spring)
Other custom FactoryBean implementations
As a result, beans that should be lazily initialized are prematurely instantiated during startup, increasing startup time and memory usage unnecessarily.
This behavior is non-obvious and invasive, especially when users have explicitly configured lazy loading (e.g., via @MapperScan(lazyInitialization = "true")).
To Reproduce
Create a Spring Boot application with:
spring-boot-starter-amqp (with RabbitAdmin auto-configured)
mybatis-spring-boot-starter
@MapperScan(basePackages = "...", lazyInitialization = "true")
Define a simple MyBatis mapper interface.
Start the application and observe logs or debug into MapperFactoryBean.getObject().
You will see that the mapper proxy is created during RabbitAdmin.initialize(), even though it's marked as lazy.
Expected behavior
RabbitAdmin should not force eager instantiation of unrelated FactoryBean instances.
Beans configured with lazy-init="true" (e.g., MyBatis mappers) should only be created when first accessed.
The presence of RabbitAdmin should not silently break lazy-loading contracts.