Friday, March 12, 2010

Annotation-Based Autowiring in Spring 2.5

Add annotations to name your DAO, service and controller classes
Chances are good that your DAO and service classes don't have the names that name-based autowiring would require. For example, you might define interfaces that have the "right" names, such as a CategoryDao interface, or a ProductService interface, and then your concrete implementation classes would be HibernateCategoryDao or ProductServiceImpl (or whatever), which won't autowire to the desired properties unless you have some strange and ill-advised property names. So our first order of business is to provide the requisite names. With manual wiring, you provide this on the <bean> element using the id or name attributes. But we're trying to eliminate said elements from our config, so that option is unavailable. We use annotations instead.

For each DAO, add a class-level @Repository annotation. These annotations go on the implementation class, not on the interface.
The @Repository annotation works in Spring 2.0 as well.

For each service component, add a class-level @Service annotation. As before, these go on the implementation class, not on the interface.

Note that @Service is new with Spring 2.5. So it won't work if you're using Spring 2.0 or earlier.

For each Spring MVC controller, add a class-level @Controller annotation.
Don't worry about providing a name; we won't need it. (So this step is a little out of place in these instructions, but go ahead and do it anyway as you will need the @Controller annotation if you want to fully autowire the web tier.) Just do this for each controller:

Like the @Service annotation, @Controller is new with Spring 2.5.
At this point we've haven't really changed anything; you still have names defined in the manual configurations in addition to the annotation-based names you've just added. Test out your app to make sure we haven't broken anything, and then move on to the next step.

We have to tell Spring two things: where to find the names, and what strategy to use (viz., autowiring by name) for autowiring.

Tell Spring where to find the annotation-based names
You will need to use the <context:component-scan> element to do this. Since it's in the context namespace, you must declare that namespace and schema location in your Spring config files. Here are examples from the data access, service, and web configurations:
In the above, the pieces relevant to component names are the xmlns:context declaration, the xsi:schemaLocation declaration, and the <context:component-scan> configuration. I'm telling Spring to scan the x.y.dao package for components that have the @Repository annotation, to scan the x.y.service package for components that have the @Service annotation, and to scan x.y.web for components that have the @Controller annotation. Spring will do that, and in the case of the data access and service components, it will use the value we provided to the annotations in step 1 above as a basis for name-based autowiring. (We didn't provide any names with the @Controller annotation though I would assume you can do that. It happens that in our case we won't need it.)
You'll notice however that I've snuck in some default-autowire="byName" attributes in there. As you can guess, that's for autowiring, and we'll look at that in just a second.

Make sure you have public setters for each bean that you want autowired
It appears that default-autowire="byName" autowiring is based on public setters. (With the @Autowired attribute applied to fields you can avoid the setters, but if you have unit tests, you'll need setters to inject mocks, and so you may as well just keep the setters and make them public. Weaker visibility doesn't appear to work)

Tell Spring that you want to use name-based autowiring
The default-autowire="byName" attribute tells Spring that you want to use component names to automatically wire up the app. In step 1 above we went through the process of providing correct names ("correct" here means names that match the injection property names) for DAO and service classes. That will allow us to remove the DAO and service components from our Spring config. In all likelihood there will be other components that you can't remove from the config, such as a Hibernate SessionFactory in your data access configuration or a TransactionManager in your services configuration. In cases like that, just make sure that the names (or IDs) that you give to the components are the ones that would be expected when doing name-based injection. Here are some examples:
Note that using default-autowire="byName" allows you to avoid having to use the @Autowired attribute on your various dependency injection fields or setters. You shouldn't have to use that at all if you follow these instructions.
At this point you should be able to remove the following configurations:
  • The DAO component definitions from your Spring data access configuration file (but don't remove the SessionFactory).
  • The service component definitions from your Spring service configuration file (but don't remove the TransactionManager).
  • The service injections from your MVC controllers in your web configuration file. Don't remove the controllers themselves for now; you still need those for defining URL mappings. Just remove the service injections since those will now be autowired. (Note that there's a way to eliminate the MVC controller configurations as well
  • The sessionFactory injection from your TransactionManager definition since that will be autowired, the dataSource injection from your SessionFactory (assuming you have an appropriate ID on the DataSource config), etc. In general just look through your configs for elements that will now be autowired and either comment them out or remove them.
I would recommend commenting things out first and then testing the app to make sure it still works.

No comments:

Post a Comment