Why Does Spring Create Two UserManager Beans? Uncovering @Configuration vs @Component Behavior

Question Description

During development, I noticed that a class annotated with both @Configuration + @Bean creates a UserManager instance with a non‑null userName, while the same class annotated with @Component creates another UserManager with a null userName. Which bean is actually injected?

The project has been running for a long time without compilation errors, and the intended behavior was to let the @Configuration + @Bean version take effect.

Spring Boot Version

The project uses Spring Boot 2.0.3.RELEASE . Bean scope is the default singleton.

Result Verification

By debugging and checking constructors, only the constructor‑based UserManager (the one defined by @Configuration + @Bean) is instantiated. The no‑arg constructor from the @Component version is never called.

Source Code Analysis

@Configuration

and @Component are closely related; ConfigurationClassPostProcessor processes @Configuration classes. It implements BeanFactoryPostProcessor and PriorityOrdered.

During component scanning, UserConfig, UserController, and UserManager are all discovered. Initially, UserManager is registered as a @Component bean definition.

Later, the @Configuration class UserConfig defines a @Bean method userManager. This bean definition overrides the previously scanned @Component definition, changing the bean type to ConfigurationClassBeanDefinition. When the bean is finally instantiated, the constructor‑based version is used.

2021-10-03 20:37:33.697  INFO 13600 --- [main] o.s.b.f.s.DefaultListableBeanFactory : Overriding bean definition for bean 'userManager' with a different definition: replacing [Generic bean: class [com.lee.qsl.manager.UserManager]; ...] with [Root bean: class [null]; ... factoryBeanName=userConfig; factoryMethodName=userManager; ...]

In Spring 5.0.7.RELEASE (Spring Boot 2.0.3.RELEASE), this overriding happens silently at INFO level.

Spring Upgrade Optimization

Starting with Spring 5.1.2.RELEASE (Spring Boot 2.1.0.RELEASE), a new configuration property allowBeanDefinitionOverriding was introduced, letting developers decide whether bean definitions may be overridden. Setting spring.main.allow-bean-definition-overriding=true enables the behavior explicitly.

When overriding is disabled, the application fails to start with a clear error indicating the duplicate bean name.

The bean 'userManager', defined in class path resource [com/lee/qsl/config/UserConfig.class], could not be registered. A bean with that name has already been defined in file [.../UserManager.class] and overriding is disabled.

This change makes the behavior more visible and configurable.

Summary

Spring 5.0.7.RELEASE (Spring Boot 2.0.3.RELEASE) allows a @Configuration + @Bean bean to override a @Component bean of the same type, logging the override at INFO level. Later versions add the allowBeanDefinitionOverriding property so developers can control this explicitly.

Supplement

Historically, Spring’s DefaultListableBeanFactory has allowed bean definition overriding by default. Spring 4.1.2 introduced the isAllowBeanDefinitionOverriding() method. Spring Boot inherited the default allowing behavior until version 2.1.0, where it introduced its own allowBeanDefinitionOverriding flag (default false) that overrides Spring’s default.