Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-7341

Allow bean definitions from @Configuration classes to override those defined in XML

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.0.3
    • Fix Version/s: None
    • Component/s: Core
    • Last commented by a User:
      false

      Description

      The ConfigurationClassBeanDefinitionReader hardcodes the behavior that bean definitions from XML always override bean definitions from JavaConfig classes:

      ConfigurationClassBeanDefinitionReader.java
      		// has this already been overridden (e.g. via XML)?
      		if (this.registry.containsBeanDefinition(beanName)) {
      			BeanDefinition existingBeanDef = registry.getBeanDefinition(beanName);
      			// is the existing bean definition one that was created from a configuration class?
      			if (!(existingBeanDef instanceof ConfigurationClassBeanDefinition)) {
      				// no -> then it's an external override, probably XML
      				// overriding is legal, return immediately
      				if (logger.isDebugEnabled()) {
      					logger.debug(String.format("Skipping loading bean definition for %s: a definition for bean " +
      							"'%s' already exists. This is likely due to an override in XML.", method, beanName));
      				}
      				return;
      			}
      		}
      

      I don't see why this decision was made. The normal semantics of using the order in which bean definitions were registered would seem to make sense to apply here as well.

      For example:

      @Configuration
      @ImportResource("foo.xml")
      class FooConfig {
        @Bean bean1() { ... }
      }
      
      @Configuration
      @ImportResource("bar.xml")
      class BarConfig {
        @Bean bean1() { ... }
        @Bean bean2() { ... }
      }
      
      ...
      new AnnotationConfigApplicationContext(FooConfig.class, BarConfig.class)
      

      I would expect the following override order to apply:
      1. beans defined in foo.xml
      2. overridden by beans defined in FooConfig
      3. overridden by beans defined in bar.xml
      4. overridden by beans defined in BarConfig

      Instead it appears the override order is:
      1. beans defined in FooConfig
      2. overridden by beans defined in BarConfig
      3. overridden by beans defined in foo.xml
      4. overridden by beans defined in bar.xml

      This is not intuitive. Specifically, note the interleaving of beans between both Foo and Bar configurations. The clients who use FooConfig and BarConfig don't care whether the beans defined by those Configuration classes come from XML or java. Yet, the override ordering forces them to be aware of this implementation detail.

      I realize changing the behavior outright might present a backwards compatibility issue, so is it possible to add a boolean option to the ApplicationContext to respect the registration ordering regardless of whether the bean definition comes from XML or JavaConfig?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                juergen.hoeller Juergen Hoeller
                Reporter:
                sirianni Eric Sirianni
                Last updater:
                Juergen Hoeller
              • Votes:
                24 Vote for this issue
                Watchers:
                21 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  1 year, 36 weeks, 5 days ago