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 yourTransactionManager
definition since that will be autowired, thedataSource
injection from yourSessionFactory
(assuming you have an appropriate ID on theDataSource
config), etc. In general just look through your configs for elements that will now be autowired and either comment them out or remove them.
No comments:
Post a Comment