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.