By Jim White (Intertech Director of Training and Instructor)
There was a small but very enjoyable group of people learning Spring in my classroom this week. I owe two of them, Bill and Uma, high praise for observing an interesting item in one of our labs that required some research on my part and is the topic of this week’s blog entry.
What Uma and Bill observed was an IDE complaining about the use of the dependency-check attribute on a bean during a Spring wiring lab (see image below).
Dependency-Check ? What is it?
If you are not familiar with the dependency-check attribute, it allows Spring developers to tell the container to insure that a property on a bean has been dependency injected. In other words, by default, Spring does not require a bean property to be dependency injected. When the dependency-check attribute is set to simple, Spring makes sure all primitive type and collection properties of the bean are set.
<bean id="ernie" class="com.intertech.Player" dependency-check="simple">
For properties that should contain a reference to another object (a ref bean), set the dependency-check attribute to objects.
<bean id="ernie" class="com.intertech.Player" dependency-check="objects">
Lastly, when all properties should be injected regardless of the property type, set the dependency-check attribute to all.
<bean id="ernie" class="com.intertech.Player" dependency-check="all">
Whenever the dependency-check fails, Spring throws a org.springframework.beans.factory.UnsatisfiedDependencyException when trying to create the bean.
So why was the IDE complaining about the dependency-check attribute? The answer is that the dependency-check attribute is deprecated in Spring 3.0 (see http://forum.springsource.org/showthread.php?p=257686#post257686). The functionality is still in Spring (and still works as we found in our labs), but the Spring team now encourages developers to use the following alternatives going forward (with Spring 3 and beyond).
- Use constructors (constructor injection instead of setter injection) exclusively to ensure the right properties are set.
- Create setters with a dedicated init method implemented.
- Create setters with @Required annotation when the property is required.
- Use @Autowired-driven injection which also implies a required property by default.
Autodetect Autowire Also Deprecated
Another small and subtle deprecation in Spring 3 is that of autowire="autodetect". Autodetect autowiring is actually a combination of constructor and byType autowiring.
<bean id="service" class="com.intertech.CustomerService" autowire="autodetect">
In autodetect autowiring, the container attempts to autowire by constructor first. If a constructor match is not found, the container then tries to autowire by type.
So what is the rationale behind deprecating the dependency-check and autowire="autodetect" attributes? According to the Spring Source forum, these features follow "not-too-obvious signature conventions and/or does not interoperate with newer annotation-based mechanisms nicely." In Spring 2.5, annotations were fully embraced and as the framework evolves through these types of changes, its evident that annotations will continue to be a strong driver in keeping the framework as clear and straightforward as possible.
My thanks again to Uma and Bill ? a couple of hard working and very observant students ? for bringing this question to my attention. If you want to learn more about Spring, I encourage you to enroll in one of our Spring classes (like our Complete Spring Core class) today. Until next time, stay warm and think Spring!