Ignore identical BeanDefinition registration when allowBeanDefinitionOverriding is false

[bironran]

Affects: 2.5.2 - 5.3, Spring Boot 2.1+

Calling DefaultListableBeanFactory.registerBeanDefinition() twice with the same bean name and same or equal BeanDefinition object results in an exception if allowBeanDefinitionOverriding was set to false (as is the default in Spring Boot 2.1+).

The javadoc for DefaultListableBeanFactory.setAllowBeanDefinitionOverriding specifically defines (emphasis is mine):

Set whether it should be allowed to override bean definitions by registering a different definition with the same name, automatically replacing the former...

Practically, this makes splitting a monolith into modules and libraries a lot harder as it bans common bean definitions due to recursive imports, e.g.:

1. Module 1 uses db hence @Import(DbConfig.class).
2. Module 2 uses db and also @Import(DbConfig.class).
3. Service 3 uses both module 1 and 2 and fails to load because of the double import if allowBeanDefinitionOverriding=false.

Allowing for silent-ignore of identical definitions will ease transitions from "one large context" to smaller modules that can be self-descriptive in their dependencies.

This behavior was introduced in #9052.

[sbrannen]

Good point, @bironran.

We aim to loosen the restrictions (as indicated by the updated title for this issue) in 5.3.x.

Thanks for bringing this up.

[jhoeller]

As far as I was able to investigate this, this is only a problem with programmatic registrations and external configuration formats such as XML, whereas double @Import usage works fine since the configuration class parser explicitly merges multiple imports for the same target class already. This should actually cover the scenario that you describe?

In general, we aim to explicitly skip re-registration (such as in the configuration class parser) rather than silently swallow it in DefaultListableBeanFactory itself. From that perspective, I'm inclined to close this issue since we do not intend to revisit the factory-level registry behavior there. If there is a concrete @Configuration/@Import scenario where this does not work as intended, feel free to reopen this issue with a corresponding test or to raise a separate issue for the specific target scenario.