Skip to content

RabbitAdmin.initialize() triggers eager instantiation of all FactoryBeans via getBeansOfType(Declarable.class, false, true) #3192

@qiuyouyao

Description

@qiuyouyao

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions