title: Spring 3 constructor injection anomaly: documentation vs. reality
body: <h1>Facts</h1>
  
  <p>Spring 3.2 documentation (<a href="http://docs.spring.io/spring/docs/3.2.9.RELEASE/spring-framework-reference/htmlsingle/#beans-constructor-injection" rel="nofollow">http://docs.spring.io/spring/docs/3.2.9.RELEASE/spring-framework-reference/htmlsingle/#beans-constructor-injection</a>):</p>
  
  <blockquote>
    <p>When another bean is referenced, the type is known, and matching can occur (as was the case with the preceding example). When a simple type is used, such as true, Spring cannot determine the type of the value, and so cannot match by type without help.</p>
  </blockquote>
  
  <pre><code>package examples;
  
  public class ExampleBean {
  
      // No. of years to the calculate the Ultimate Answer
      private int years;
  
      // The Answer to Life, the Universe, and Everything
      private String ultimateAnswer;
  
      public ExampleBean(int years, String ultimateAnswer) {
          this.years = years;
          this.ultimateAnswer = ultimateAnswer;
      }
  }
  </code></pre>
  
  <blockquote>
    <p>In the preceding scenario, the container can use type matching with simple types if you explicitly specify the type of the constructor argument using the type attribute. For example:</p>
  </blockquote>
  
  <pre><code>&lt;bean id="exampleBean" class="examples.ExampleBean"&gt;
      &lt;constructor-arg type="int" value="7500000"/&gt;
      &lt;constructor-arg type="java.lang.String" value="42"/&gt;
  &lt;/bean&gt;
  </code></pre>
  
  <p>My class:</p>
  
  <pre><code>package client;
  
  public class Client {
  
      private int id;
      private String name;
  
      public Client(int id, String name, String email) {
          super();
          this.id = id;
          this.name = name;
      }
  
  }
  </code></pre>
  
  <p>bean definition:</p>
  
  <pre><code>&lt;bean id="someClient" class="client.Client"&gt;
      &lt;constructor-arg value="5"&gt;&lt;/constructor-arg&gt;
      &lt;constructor-arg value="5"&gt;&lt;/constructor-arg&gt;
      &lt;constructor-arg value="5"&gt;&lt;/constructor-arg&gt;
  &lt;/bean&gt;
  </code></pre>
  
  <h1>Problem</h1>
  
  <p>I would have expected that the Spring IoC container will fail to create the bean <em>someClient</em>, since as stated above, it should be unable to address the types of constructor arguments specified. But, again, according to the docs a bit earlier:</p>
  
  <blockquote>
    <p>If no potential ambiguity exists in the constructor arguments of a bean definition, then the order in which the constructor arguments are defined in a bean definition is the order in which those arguments are supplied to the appropriate constructor when the bean is being instantiated.</p>
  </blockquote>
  
  <p>But alas, Spring registers the <em>someClient</em> bean effortlessly. This seems like a contradiction to me.</p>
  
  <h1>Question</h1>
  
  <p>So what is an ambiguous situation, according to Spring? The above example is clearly not ambiguous, Spring happily supplies the arguments in the order as they are defined in the bean definition. When is it really useful to use name/index attributes in the bean definition?</p>