With errors that are hard to track, and with XML bean definitions taking always precedence over Java config (which can be surprising), we'd like to deprecate bean overriding wholesale with the idea of removing the feature at some point.

Spring Boot has already paved the way by disabling it by default and introducing a property to opt-in to the previous behavior. Us deprecating the feature in the core framework should send a strong signal to developers that they should not rely on that feature anymore.

Comment From: dearoneesama

It scares me off, but It looks like we are not talking about overriding @Bean-decorataed methods right?

Comment From: snicoll

registering twice a bean definition for the same key (i.e. bean name).

Comment From: mmoayyed

Us deprecating the feature in the core framework should send a strong signal to developers that they should not rely on that feature anymore.

Could you please elaborate on how one might go about doing the same sort of thing when the particular bean is not marked as conditional? For example, what is the right strategy for overriding this bean?

@Bean
public MessageSource messageSource(MessageSourceProperties properties) {}
  • Should we exclude the configuration class?
  • Should we examine the conditions that trigger the creation of this bean and rework the app to disable those conditions? (In this case, rename the language bundle?)
  • Could we start sending pull requests that mark such beans with a @ConditionalOnMissingBean and family?

Comment From: snicoll

So we're going to change this particular issue to log a warning that indicates why it is being logged and that a next release will make it more noisy. We will also update the reference guide to indicate that users should move away from that feature and how. Once that's done we will advocate the Spring Boot property to be deprecated.

Deprecation of the feature proper is now scheduled for Spring Framework 7 to give enough room for users to notice and plan accordingly.

@mmoayyed If you want to override it in your configuration, it won't be possible and the mitigation will happen on a case by case basis. For tests, we are working to give users a first class support for overriding specific beans.

Comment From: snicoll

We probably need to rephrase the note in https://docs.spring.io/spring-framework/reference/6.2-SNAPSHOT/testing/annotations/integration-spring/annotation-beanoverriding.html#spring-testing-annotation-beanoverriding-mockitobean.

In the meantime support for bean overriding in tests has landed in 6.2.0-SNAPSHOT. The doc above provides an overview if you want to give the snapshots a try.

Comment From: snicoll

Giving this a try on our own projects revealed quite a number of issues. If we pursue with this, we should probably introduce a flag that we can use to opt-in for an exception as the warning alone makes it harder to validate that things are working as expected.

Comment From: snicoll

This is where we are with my testing https://ge.spring.io/s/rx7ixhsvowv4m