In the previous post, we discussed the Spring IoC containers and the differences between them. In this post, we will learn about autowiring, its different modes, and its limitations in Spring.
Normally, we define bean configuration details in the Spring configuration file and explicitly specify the dependencies to be injected into other beans using the ref attribute. However, the Spring Framework also provides an autowiring feature, which eliminates the need to specify these dependencies explicitly.
Autowiring is the process of automatically injecting a bean's dependencies. Instead of configuring dependencies manually, Spring examines the beans available in the IoC container and automatically establishes the required relationships between collaborating beans.
Spring provides the following five autowiring modes:
- no:
This is the default autowiring mode, which means that autowiring is disabled. Dependencies must be configured manually using the ref attribute.
Example: Using the ref attribute
<bean id="chat" class="com.test.Chat"> <property name="messageType" ref="message"> </property> </bean> <bean id="message" class="com.test.Message" > </bean>
- byName:
Autowiring by Name
In this mode, Spring performs autowiring based on the property name. If the name of a bean matches the name of a property in another bean, Spring automatically injects that bean through the corresponding setter method.
Example:
In the example below, the bean named message has the same name as the message property of the chat bean. Therefore, Spring automatically injects the message bean into the chat bean by invoking the setter method:
setMessage(Message message)
<bean class="com.test.Chat" id="chat" autowire="byName"> </bean> <bean class="com.test.Message" id="message"> </bean>
Chat.java,
public class Chat{ private Message message; // other properties public void setMessage(Message message){ this.message = message; } }
- byType:
Autowiring by Type
In this mode, Spring performs autowiring based on the property data type. If the data type of a bean matches the data type of a property in another bean, Spring automatically injects the bean through the corresponding setter method.
Example:
In the example below, the data type of the message bean matches the data type of the message property in the chat bean. Therefore, Spring automatically injects the message bean into the chat bean by invoking the following setter method:
setMessage(Message message)
Configuration File:
<bean class="com.test.Chat" id="chat" autowire="byType"> </bean> <bean class="com.test.Message" id="message"> </bean>
Chat.java,
public class Chat{ private Message message; // other properties public void setMessage(Message message){ this.message = message; } }
- constructor:
Autowiring by Constructor
In this mode, Spring performs autowiring based on the constructor argument type. If the data type of a bean matches the data type of a constructor parameter, Spring automatically injects the bean through the constructor.
Example:
In the example below, the data type of the message bean matches the data type of the constructor parameter in the Chat class. Therefore, Spring automatically injects the message bean by invoking the following constructor:
public Chat(Message message)
Configuration File:
<bean class="com.test.Chat" id="chat" autowire="constructor"> </bean> <bean class="com.test.Message" id="message"> </bean>
Chat.java,
public class Chat{ private Message message; // other properties public Chat(Message message){ this.message = message; } }
- autodetect:
Limitations with Autowiring:--
Explicit configuration overrides autowiring: Dependencies specified explicitly using the
constructor-argorpropertyelements always take precedence over autowiring.Simple properties cannot be autowired: Spring cannot autowire simple properties such as primitive types,
String,Class, or their wrapper classes (for example,IntegerandBoolean). These values must be configured explicitly using thepropertyorconstructor-argelements.Can make configuration harder to understand: In applications with many dependencies, autowiring can make it more difficult to determine how beans are connected. Since the dependencies are resolved automatically by the container, understanding and debugging the application configuration may become more challenging.

No comments:
Post a Comment