javaconf: beans with same name in independent conf files should cause an error [SPR-8525]

[spring-projects-issues]

Stepan Koltsov opened SPR-8525 and commented

public class QuietlyOverrides {

@Configuration
public static class Conf1 {

    @Bean
    public Inflater inflater() {
        System.out.println("1");
        return new Inflater();
    }

}

@Configuration
public static class Conf2 {

    @Bean
    public Inflater inflater() {
        System.out.println("2");
        return new Inflater();
    }

}

@Configuration
@Import({ Conf1.class, Conf2.class })
public static class Conf {
}

public static void main(String[] args) {
    // expecting an exception        // Spring quietly creates only second bean        new AnnotationConfigApplicationContext(Conf.class);
    System.out.println("$");
}

} //~

We have large application, and one developer accidentally created a bean with name same as name of bean in another part of application. Problem search was not easy.

I think Spring should throw an error if independent configurations declare beans with same name. Configurations are independent if neither of which include another configuration directly or indirectly.

However, IF Conf2 includes Conf1, Spring should quietly override bean declared in Conf1 with bean declared if Conf2, as it does now. It is convenient to "inherit" configuration and override some bean definitions.

---

Affects: 3.1 M2

[spring-projects-issues]

Chris Beams commented

Hi Stepan,

While your request is understandable, it's probably not something we can reasonably change, for a couple reasons:

1. The way that bean definition overriding works in the @Bean world is currently consistent with the way it works in the <bean> world. As such, it behaves as a Spring user would expect if they understand XML configuration.

2. Changing this behavior now would represent a breaking of backward compatibility. i.e. users may be depending on a @Bean method in one @Configuration class overriding another identically named @Bean method from another @Configuration class, regardless of whether the former class @Import'ed the latter.

However, there is some good news: if you're not already aware, both AbstractRefreshableApplicationContext and GenericApplicationContext expose a #setAllowBeanDefinitionOverriding property. You can set this at bootstrap time, possibly through an ApplicationContextInitializer if working with a webapp.

Hope that can meet your needs!

Chris

[spring-projects-issues]

Stepan Koltsov commented

Chris, unfortunately setAllowBeanOverriding(false) does not help, because I still want to override some beans.

But as you pointed, backward compatibility should be preserved, so I made alternative feature request: #13172.