Spring 2.5 – Heavily Auto-Wired

Concept to auto-wire relationships among spring enabled beans has always been there. The idea with auto-wiring is to get away from the tedious task of specifying and more importantly maintaining explicit wiring. Originally it was supported to be done by name, by type, by constructors or auto-detect and then you had the option to auto-wire all or specific beans within a context. But now with Spring 2.5 the auto wiring concept has taken a whole new meaning and so is the debate if we really want to do auto-wiring.

Spring 2.5 has a new @Autowire annotation. @Autowire annotation let us do much fine grained auto-wiring then was possible before and also it make us much more explicit then was possible in pre Spring 2.5 times

Lets consider few examples

public void init(AccountDao accountDao, CustomerDao customerDao) {
	this.accountDao = accountDao;
	this.customerDao = customerDao;

Do not need to have setters with one parameter to inject dependencies, any method with any name and any number of parameters will do. Can be applied to fields and constructors as well and obviously to the favorite setters 🙂


private BaseDao[] daos;


private Set<BaseDao> daos;

Create an array or collection with all the possible beans available in the context..


private AccountDao accountDao = new AccountDao();

Find it do it, if not leave it.

Moving on we can even fine control this by using another annotation @Qualifier. Again lets see some more examples

private BankService bkService;

We are doing by-name auto-wiring by providing a bean name within the annotation. This might help by letting you declare the name of the property different from the name of the bean.

#5 – Example of custom qualifier annotations to take care of the case when we have more then one implementation which we want to auto-wire
Define an annotation like this

@Target({ElementType.FIELD, ElementType.PARAMETER})
public @interface Category {
    String value();

Custom qualifier on autowired fields can be applied like this

public class BookList {
    private Book technicalBook;

    private Book managementBook;


and then do the bean definitions like this

<bean name="book" class="example.Book">
    <qualifier type="Category" value="Technical"/>
    <!-- This implementation specific properties -->
<bean name="book" class="example.Book">
    <qualifier type="Category" value="Management"/>
    <!-- This implementation specific properties -->

And if this is not enough we can always create a custom auto-wire configurer or may be use the new @Resource annotation
for further auto-wiring stuff.

That is that for auto-wiring but Spring 2.5 introduces a concept of auto-detection of spring components on the classpath where we do not have to even define the beans (with the name and bean class) in the context. Spring does a component scanning on the classpath (which can be configured using filters) by detecting classes which are stereotyped and then registering them as spring enabled beans.

Yes it provides a lot of flexibility and a much greater control as can be seen from all of the above examples but still I feel it should be done with a lot of caution and I-am-going-to-be-consistent attitude.

Comments (4)

  1. Jan - Reply

    November 22, 2007 at 12:28 pm

    To me "Auto-Wiring" has always been too magical. In my view it can lead to hard to maintain software.

  2. Peter Veentjer - Reply

    November 28, 2007 at 1:01 pm

    I agree. I think it should not be used on projects of considerable size and I\'ll certainly will protest if somebody is going to use it.

    Not writing code is not always better: some stuff should be made explicit. In a sense explicit wiring in the Spring application contexts documents how the bean is used. It is a shame if this executable documentation gets lost.

  3. Alef Arendsen - Reply

    November 29, 2007 at 7:04 pm

    [quote]I\’ll certainly will protest if somebody is going to use it.[/quote]

    😉 That's how I know you! 😉

    What about a tiny part of your application, such as the web layer, where (using the new @Controller support) it allows you to get almost Rails-like behavior with controller being automatically picked up?

    I agree that it's a pity that you will be losing the application's documentation--however Spring IDE will support rendering of graphs based on autowired beans in the (near) future. Still, this is tooling and the underlying config file does not express the relations explicitly anymore...


  4. Allen - Reply

    February 20, 2008 at 8:56 am

    i want to use @Resource or @Autowire to make a prototype bean , how to do it ?


Add a Comment