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

Doc: @Configuration class accepts overloaded factory methods for same bean

    Details

    • Type: Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: 4.2.1
    • Fix Version/s: 4.2.3
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      I do not expect a single @Configuration class accepting several beans with the same name. I guess it should follow the same contract in XML where one could not define in the same XML 2 bean with the same id.

      Here is a test demonstrating the behavior. I guess there is no know knowing which bean has been accepted, and this would change from one environment to another.

      package blasd.apex.server.datastore.tuple;
       
      import org.junit.Test;
      import org.junit.runner.RunWith;
      import org.springframework.beans.factory.annotation.Autowired;
      import org.springframework.context.annotation.Bean;
      import org.springframework.context.annotation.Configuration;
      import org.springframework.test.context.ContextConfiguration;
      import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
       
      @RunWith(SpringJUnit4ClassRunner.class)
      @ContextConfiguration(classes = { TestSameConfDiffBeanSamename.class })
      @Configuration
      public class TestSameConfDiffBeanSamename {
      	@Bean
      	public String firstBean() {
      		return "youpi";
      	}
       
      	@Bean
      	public Integer someBeanName(String someString) {
      		return someString.length();
      	}
       
      	@Bean
      	public Integer someBeanName() {
      		return 1;
      	}
       
      	@Autowired
      	Integer someInteger;
       
      	@Test
      	public void wonderingWhichIntegerWillArrive() {
      		System.out.println(someInteger);
      	}
      }
      

      Regards

        Activity

        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        While this isn't properly documented, it is a supported feature - but not for defining multiple beans of the same name, rather just for providing various factory methods for the same bean. This is then the same algorithm as for choosing the "greediest" constructor or factory method in other configuration scenarios: Depending on the available dependencies, the variant with the largest number of satisfiable dependencies is being picked.

        Compare a component class where several constructors are marked with @Autowired; several same-named @Bean methods are an analogous arrangement for factory methods. And with XML, a "factory-method" name will be resolved analogously against all declared methods of that name - the same way that a constructor will be resolved among all candidates for an XML bean definition using autowire="constructor".

        Turning this issue into a documentation task, since this needs to be better documented.

        Juergen

        Show
        juergen.hoeller Juergen Hoeller added a comment - While this isn't properly documented, it is a supported feature - but not for defining multiple beans of the same name, rather just for providing various factory methods for the same bean. This is then the same algorithm as for choosing the "greediest" constructor or factory method in other configuration scenarios: Depending on the available dependencies, the variant with the largest number of satisfiable dependencies is being picked. Compare a component class where several constructors are marked with @Autowired ; several same-named @Bean methods are an analogous arrangement for factory methods. And with XML, a "factory-method" name will be resolved analogously against all declared methods of that name - the same way that a constructor will be resolved among all candidates for an XML bean definition using autowire="constructor". Turning this issue into a documentation task, since this needs to be better documented. Juergen

          People

          • Assignee:
            juergen.hoeller Juergen Hoeller
            Reporter:
            blasd Benoit Lacelle
            Last updater:
            St├ęphane Nicoll
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              2 years, 24 weeks, 5 days ago