CODEWITHSUNDEEP
javaspring
willcodejavaforfood
willcodejavaforfood

Reputation: 44083

Spring, @Autowired, @Resource and <property>

This week I've been trying to learn Spring, JBoss, Maven, JPA and Hibernate and I've had a lot of fun with it. I am somewhat confused over the many different ways to inject resources in a class though. Until this week I was not even aware that you could inject resources in any other way than using the <property> tag in your Spring XML configuration.

<bean id="catalogService" class="com.idbs.omics.catalog.service.CatalogService">
    <property name="termDao" ref="termDao"></property>
</bean>

When I started experimenting with JPA I encountered @PersistenceContext, but that seems to be a special case so fair enough. Then I started reading up on Spring's testing framework and I saw the first example that used @Resource(name="catalogService") and then in a Web Service example @Autowired crashed the party!

**The Question!**

So what is the difference between all these and is there right and wrong situation to use them in? I guess I'm looking for a best practice here.

Cheers all

Upvotes: 7

Views: 6159

Answers (2)

Sean Patrick Floyd
Sean Patrick Floyd

Reputation: 299108

@Autowired, @Resource and @Inject

I think the part of the Spring Reference that you need to read is

3.9 Annotation-based container configuration

There are many sets of similar annotations. Often, there is a Spring and a non-Spring version that do the same thing. Spring tries to embrace standards whenever they are available, but often the Spring guys came up with their own ideas before a standard appeared. Example: Spring supports its own @Autowired annotation, but also the new @Inject annotation from JSR-330, as well as the JSR-250 @Resource annotation (all of which can be used to do the same thing).

The key concept here is that Spring doesn't force you to use its own code, but supports many different ways without coupling your application to Spring. (There are still a few annotations that have no non-Spring equivalent, like @Transactional, but if you want to, you can add that functionality via XML instead, so you can keep your application 100% Spring free and still use many convenience annotations and of course Spring wiring and lifecycle management behind the scenes.

Upvotes: 13

Stephen C
Stephen C

Reputation: 719336

The other aspect of this is when to use annotations and when to use XML spring wiring files.

My view is that this is a trade-off between code readability and the ability to reconfigure.

  • If you use annotations, then you can see from just the source code what is wired to what. By contrast, if you use XML wiring files, you have two places to look.

  • If you use XML wiring files, you can make configuration changes by modifying (or with Maven overlaying) the XML wiring files. If you are bold, you can even do this on a deployed webapp. By contrast, changing the IoC wirings when annotations are used requires you to modify the Java files and recompile.

(Aside: in the case of the second bullet, the ideal situation would be to have a nice GUI-based tool for reconfiguring the wirings that could be run in either your development sandbox, or the deployed webapp folder. Does anyone know of such a tool?)

Upvotes: 2

Related Questions