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
#1

@Autowired
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

#2

@Autowired
private BaseDao[] daos;

or

@Autowired
private Set<BaseDao> daos;

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

#3

@Autowired(required=false)
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
#4

@Autowired
@Qualifier("bankService")
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})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Category {
    String value();
}

Custom qualifier on autowired fields can be applied like this

public class BookList {
    @Autowired
    @Category("Technical")
    private Book technicalBook;

    @Autowired
    @Category("Management")
    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>
<bean name="book" class="example.Book">
    <qualifier type="Category" value="Management"/>
    <!-- This implementation specific properties -->
</bean>

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.

So this is good if we want to create a sub class of a specific type for each row but what about if we want to create an instance of a specific class for a value of a column within that row. So in a way some type of component inheritance mapping. This is required if I really do not want to convert a value object (component) into an entity as that might mean sacrifice on the part of good model design as I am loosing the distinction between a component and an entity.

A workaround for the moment could be to somehow use a UserType to create instance of such objects based upon the value stored in the column. The concept of discriminator column can still help us. Let’s see how by taking up the following example

Suppose we have a catalog of books where each book has a price specification depending upon the currency of where the book was originally published. Each price specification is modeled by a separate class which has a property amount. Assume here that these classes have a different behavior depending upon the currency for calculation of sales tax and stuff (otherwise we can simply create a class and do the mapping using component or one-to-one).

So the book table looks something like this

CREATE TABLE BOOK (
    ID NUMBER(19,0) NOT NULL,
    PRICE_SPEC_TYPE VARCHAR2(3) NOT NULL,
    PRICE_AMOUNT    NUMBER(19,0) NOT NULL,
    …
);

And book class like this

public class Book {
    private long id;
    private PriceSpecification priceSpecification;
    …
}

And one of the price specifications may be

public class USDollarSpecification implement PriceSpecification {
    private long amount;
    public void setAmount(long amount) {
        this.amount = amount;
    }
    public long getMaximumRetailPrice() {
    }
    …
}

Now this can be obviously mapped using a UserType but to make it much cleaner lets use an Enum. Some sample code of PriceSpecificationUserType looks something like this.

public Object nullSafeGet(ResultSet rs, String[] names, Object owner) throws HibernateException, SQLException {
    String type = rs.getString(names[0]);
    long amount = rs.getLong(names[1]);
    PriceSpecificationType priceSpecType = priceSpecificationType.valueOf(type);
    PriceSpecification specification = priceSpecType.getNewInstance();
    specification.setAmount();
    return specification;
}

Here we create an instance of a price specification from the value in PRICE_SPEC_TYPE column using an Enum for price specification types.

public void nullSafeSet(PreparedStatement preparedStatement, Object value, int index) throws HibernateException, SQLException {
    if (value == null) {
        preparedStatement.setNull(index, Types.VARCHAR);
        preparedStatement.setNull(index + 1, Types.NUMERIC);
    } else {
        PriceSpecification priceSpecification = (PriceSpecification) value;
        String className = priceSpecification.getClass().getName();
        PriceSpecificationType[] priceSpecTypes = PriceSpecificationType.values();
        for (int i = 0; i < priceSpecTypes.length; i++) {
            PriceSpecificationType priceSpecType = priceSpecTypes[i];
            if (priceSpecType.getClassName().equals(className)) {
                preparedStatement.setString(index, priceSpecType.name());
                break;
            }
        }
        preparedStatement.setInt(index + 1, priceSpecification.getAmount());
    }
}

And similarly we set the price specification in PRICE_SPEC_TYPE using the Enum for price specification types.

Here is how Enum looks like

public enum PriceSpecificationType {
    US_DOLLAR {
        public String getClassName() {
            return USDollarSpecification.class.getName();
        }

        @Override
        public PriceSpecification getNewInstance() {
            return new USDollarSpecification();
        }
    },
    …

    public abstract PriceSpecification getNewInstance();

    public abstract String getClassName();
}

And finally let’s see the mapping for this

<typedef name="PriceSpecification" class="PriceSpecificationUserType"/>

<class name=”Book” table=”BOOK”
    <property name="priceSpecification" type="PriceSpecification">
        <column name="PRICE_SPEC_TYPE"/>
        <column name="PRICE_AMOUNT"/>
    </property>
</class>

Hibernate might add a support for this in one of the future releases going by this http://opensource.atlassian.com/projects/hibernate/browse/HHH-1152 but for now this might be a workaround we have to live with