Is spring.main.allow-bean-definition-overriding=true a bad practice

Question

I am building a Spring Boot Rest API server to port a legacy application on a more robust framework. That is my first project using those technologies. So far I have built a proof of concept with 2 API that reply "Hello world!" in JSON. One is open and the other is secured with OAuth2. I am done tuning the security up to the requirement.

I have also built a strong test structure using a combination of Rest-Assured for integration tests and Spring MockMvc for unit tests, so I am confident I am ready to start implementing real API using a TDD approach.

We are using Maven. My problem is that as soon as I had a dependency with our existing artifacts, I get the following stack. I understand what it means but our codebase is huge and I can't find out where this comes from. When I ask Google about this problem, I often find result simply suggesting to add spring.main.allow-bean-definition-overriding=true to my properties. Isn't this just sweeping the problem under the rug ? I would guess there is a very good reason why Spring doesn't allow this by default. What are the possible consequences of simply ignoring that error with a convenient application properties ?

The stack :

*************************** APPLICATION FAILED TO START
***************************

Description:

The bean 'org.springframework.transaction.config.internalTransactionAdvisor', defined in class path resource [org/springframework/transaction/annotation/ProxyTransactionManagementConfiguration.class], could not be registered. A bean with that name has already been defined in null and overriding is disabled.

Action:

Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true

[WARNING]  java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:558)
    at java.lang.Thread.run (Thread.java:748) Caused by: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'org.springframework.transaction.config.internalTransactionAdvisor' defined in class path resource [org/springframework/transaction/annotation/ProxyTransactionManagementConfiguration.class]: Cannot register bean definition [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration; factoryMethodName=transactionAdvisor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/transaction/annotation/ProxyTransactionManagementConfiguration.class]] for bean 'org.springframework.transaction.config.internalTransactionAdvisor': There is already [Root bean: class [org.springframework.transaction.interceptor.BeanFactoryTransactionAttributeSourceAdvisor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] bound.
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition (DefaultListableBeanFactory.java:897)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod (ConfigurationClassBeanDefinitionReader.java:274)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass (ConfigurationClassBeanDefinitionReader.java:141)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitions (ConfigurationClassBeanDefinitionReader.java:117)
    at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions (ConfigurationClassPostProcessor.java:327)
    at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry (ConfigurationClassPostProcessor.java:232)
    at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors (PostProcessorRegistrationDelegate.java:275)
    at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors (PostProcessorRegistrationDelegate.java:95)
    at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors (AbstractApplicationContext.java:705)
    at org.springframework.context.support.AbstractApplicationContext.refresh (AbstractApplicationContext.java:531)
    at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh (ServletWebServerApplicationContext.java:142)
    at org.springframework.boot.SpringApplication.refresh (SpringApplication.java:775)
    at org.springframework.boot.SpringApplication.refreshContext (SpringApplication.java:397)
    at org.springframework.boot.SpringApplication.run (SpringApplication.java:316)
    at org.springframework.boot.SpringApplication.run (SpringApplication.java:1260)
    at org.springframework.boot.SpringApplication.run (SpringApplication.java:1248)
    at ca.mycompany.oav.ResourceServerApplication.main (ResourceServerApplication.java:22)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:558)
    at java.lang.Thread.run (Thread.java:748)

Some spring defaults seem better reasoned than others (looking at you, OSIV) but this one seems sensible. [this question](https://stackoverflow.com/q/54059222/217324) seems relevant. — Nathan Hughes, May 17 '19 at 15:01
I've never used it. Feels like you should review your bean definitions. — duffymo, May 17 '19 at 15:12

score 3 · Answer 1 · answered Mar 09 '21 at 14:01

Just to be aware that: by adding this, it is difficult to guess which bean will have priority because the bean creation order is determined by dependency relationships mostly influenced in runtime. Therefore, allowing bean overriding can produce unexpected behavior unless we know the dependency hierarchy of our beans well enough.

Reference

score 1 · Answer 2 · answered Jul 28 '21 at 14:01

spring.main.allow-bean-definition-overriding=true concerns overriding beans using the same bean name as an existing bean. If the bean is in your own code, you can always just change the bean name (if using @Bean, the name is by default the method name, or the class name for @Component; but there are different ways to set the bean name, check the docs).

So the only reasonable (as far as I can think) reason to set this flag is if multiple beans that you don't control (i.e. from 3rd party code) are loaded with the same name.

Note that in case you're having multiple beans with the same type, autowiring this bean without using a name/qualifier will cause initialization to crash. — David Barda, Jan 09 '23 at 09:32

score 0 · Answer 3 · answered Jul 26 '21 at 07:48

Answer is

No don't use overriding as much as possible. But at times may be (but with caution)

To understand this better,

When you start the Application, Spring Boot auto-loads many beans (to provide out-of-the-box functionalities) some may be required some may not be. There are two options we have

Option #1:

Let Spring Boot Load the functionality
You later override

Option #2:

Ask Spring Boot not to load what you don't need.
Just add your own bean

Example Use-case

Spring Boot provides out of the box Cloud Configuration with ConfigServicePropertySourceLocator. in a realtime scenario, we will have our own secured config server to use instead of the default one.

Option #1:

Let Spring Boot Load ConfigServicePropertySourceLocator Bean
Enable overriding by specifying spring.main.allow-bean-definition-overriding=true
Define you custom Bean, But make sure you add @Order, @Primary etc.

Option #2:

Ask Spring Boot not load ConfigServicePropertySourceLocator by adding spring.cloud.config.enabled=false
Just Define you custom Bean.

You save startup time also code looks clean.

Ref: https://github.com/spring-cloud/spring-cloud-config/issues/177

This answer is somewhat incorrect (or at least misleading), because `spring.main.allow-bean-definition-overriding=true` concerns overriding existing beans *with the same bean name*. Your example is about overriding with the same bean type, which is always allowed. — jhyot, Jul 26 '21 at 07:56
Yes. It is completely allowed to override by name or by priority. Nut Idea is to avoid overriding as much as possible . If we have option disable the default behaviour and load your custom components. — Sathish Kumar Thiyagarajan, Jul 28 '21 at 03:05

Is spring.main.allow-bean-definition-overriding=true a bad practice

3 Answers3

Example Use-case