Autowiring

Spring have many collaborating bean, the autowire help in making the relationship between them.

Autowiring reduces the effort of writing properties or constructor arguments. The autowiring in specified at the autowire attribute inside <bean/> element. 

We know to declare beans using the <bean> element and inject <bean> with using <constructor-arg> and <property> elements in XML configuration file.

<bean name="beanA" class="BeanA">
   <property name="beanB"><ref bean="beanB"/></property>
</bean>
<bean name="beanB" class="BeanB" />
<bean name="beanC" class="BeanC">
   <property name="beanA"><ref bean="beanA"/></property>
   <property name="beanB"><ref bean="beanB"/></property>
</bean>

<bean name="beanA" class="BeanA">
    <constructor-arg index="0"><ref bean="beanB"/></constructor-arg>
</bean>

<bean name="beanB" class="BeanB" />

<bean name="beanC" class="BeanC">
    <constructor-arg index="0"><ref bean="beanA"/></constructor-arg>
    <constructor-arg index="1"><ref bean="beanB"/></constructor-arg>
</bean>

The Spring container can autowire relationships between collaborating beans WITHOUT using <constructor-arg> and <property> elements which helps cut down on the amount of XML configuration you write for a big Spring based application.

The Spring container is able to autowire relationships between collaborating beans. This means that it is possible to automatically let Spring resolve collaborators (other beans) for your bean by inspecting the contents of the BeanFactory. The autowiring functionality has five modes. Autowiring is specified per bean and can thus be enabled for some beans, while other beans will not be autowired. 

Limitations with autowiring:

Autowiring works best when it is used consistently across a project. If autowiring is not used in general, it might be confusing to developers to use it to wire only one or two bean definitions. Though, autowiring can significantly reduce the need to specify properties or constructor arguments but you should consider the limitations and disadvantages of autowiring before using them.

Limitations	Description
Overriding possibility	You can still specify dependencies using <constructor-arg> and <property> settings which will always override autowiring.
Primitive data types	You cannot autowire so-called simple properties such as primitives, Strings, and Classes.
Confusing nature	Autowiring is less exact than explicit wiring, so if possible prefer using explict wiring.

Mode	Explanation
no	No autowiring at all. Bean references must be defined via a ref element. This is the default, and changing this is discouraged for larger deployments, since explicitly specifying collaborators gives greater control and clarity. To some extent, it is a form of documentation about the structure of a system.
byName	Autowiring by property name. This option will inspect the BeanFactory and look for a bean named exactly the same as the property which needs to be autowired. For example, if you have a bean definition which is set to autowire by name, and it contains a master property (that is, it has a setMaster(...) method), Spring will look for a bean definition named master, and use it to set the property.
byType	Allows a property to be autowired if there is exactly one bean of the property type in the BeanFactory. If there is more than one, a fatal exception is thrown, and this indicates that you may not use byType autowiring for that bean. If there are no matching beans, nothing happens; the property is not set. If this is not desirable, setting the dependency-check="objects" attribute value specifies that an error should be thrown in this case.
constructor	This is analogous to byType, but applies to constructor arguments. If there isn't exactly one bean of the constructor argument type in the bean factory, a fatal error is raised.
autodetect	Chooses constructor or byType through introspection of the bean class. If a default constructor is found, byType gets applied.