We've been utilizing <constructor-arg> and <property> to inject dependencies. Instead, we can autowire the dependencies, which helps to diminish the measure of configurations that should be composed.

There are diverse choices for auto-wiring that manage the Spring container on the most proficient method to infuse the conditions. A bean has no auto-wiring by default. 

Here are the two major types of auto-wiring:

• byName: To autowire a bean, the Spring container chooses the bean by the class name. Here's an example of the use of byName:

<bean id="app" class="App" autowire="byName"/>

• byType: To autowire a bean, the Spring container chooses the bean according to the class type. Here is an example of the use of byType:

<bean id="app" class="App" autowire="byType"/>

If there are multiple implementing classes for a Service interface, you'll find two types of scenario.

In the case of services (a cluster of services execute the Service interface), bean won't allow us to execute the autowire of byName. If there isn't an occurrence of byName, it will inject all the executing objects.

In the case of mainService (an object actualizes the Service interface), for the byType/constructor, allocate the autowire-applicant attribute in the <bean> tag of all executing classes as false, keeping one of them as true.

Here's an example of how to handle multiple implementing classes for a Service interface in beans.xml:

<?xml version = "1.0" encoding = "UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <!--Beans Auto-Wiring Example Start-->
    <bean id="userGreeting" class="ktPackage.UserGreeting" autowire="byType"/>
    <bean id="userSurname" class="ktPackage.UserSurname" autowire-candidate="true"/>
    <bean id="xxxxx" class="ktPackage.XXXX" autowire-candidate="false"/> <!--demoClass-->
    <bean id="yyyyy" class="ktPackage.YYYY" autowire-candidate="false"/> <!--demoClass-->
    <!--SBeans Auto-Wiring Example End-->
</beans>

For byName, either rename mainService in the application class to one of the actualizing classes (that is, userSurname), or rename the bean id of that class in the XML configuration to mainService:

<?xml version = "1.0" encoding = "UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <!--Beans Auto-Wiring Example Start-->
    <bean id="userGreeting" class="ktPackage.UserGreeting" autowire="byName"/>
    <bean id="mainService" class="ktPackage.UserSurname"/>
    <bean id="xxxxx" class="ktPackage.XXXX"/> <!--demoClass-->
    <bean id="yyyyy" class="ktPackage.YYYY"/> <!--demoClass-->
    <!--SBeans Auto-Wiring Example End-->
</beans>

Here are some limitations of auto-wiring:

• Overriding possibility: To specify the dependencies, you can use the <constructor-arg> and <property> settings, which will override auto-wiring.
• Primitive data types: Primitives, strings, and classes can't be called.
• Confusing nature: Auto-wiring is less accurate than unequivocal wiring.