This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Also, what is the whole point of having @Qualifier and @Resource annotation? It is supposed to let the programmer wire a specific bean from within Java code, if such bean binding was not possible in the config file.
But if @Qualifier is using the bean id in the annotation, it totally loses its significance of autowiring (via @Autowired annotation), which exists to rid specific beans to be linked to properties. Ditto with @Resource annotation.
The point is if we were to specify a name for a bean, we could simply do it using the ref attribute in XML, keeping the config file more readable and understandable.
The only place where I believe @Qualifier and @Resource would come to use is, when you want to keep control of a bean property in class programmatically on a class-by-class basis not depending on the ref attribute to make the reference to a bean in the config file.
Am I confusing things...let me know. Would love to discuss.
@Autowired is Spring's Annotation(only usable in Spring)
@Resource is JSR-250 Common Annotation equivalent (works the same in Java EE 5)
@Inject is JSR 33? Common Annotation equivalent. (works the same in Java EE 6?)
All three do the same thing. However, @Autowired is the only annotation of the three that you can put on constructors.
Now since auto wiring by default does it by object type. If you have two beans of the same type, then there is ambiguity that Spring can't figure out which of the two beans to inject. That is what @Qualifier is for, to use the bean name to fix the ambiguity and tell Spring which of the two beans to inject. Use @Qualifier with @Autowired. With @Resource and @Inject you can just put the bean name in the annotation as an attribute.
The point that I was making is:
If you would use the bean id alongwith @Qualifier (in conjunction with @Autowired) and @Resource, I believe it is the same as using a ref attribute in the bean declaration.
What do you think?
I think this would be useful in a scenario where you have the beans created and loaded in the context using the bean config. Consider class A and class C has property of object type of class B. BeanA corresponds to this class A. There are two beans BeanB1 and BeanB2 defined for class B. And BeanC for class C.
So I believe now we can have two beans for components B and C referencing to a bean of class B, BUT, in the source of class A and class C, using the @Qualifier and @Resource we can make it point to BeanB1 and BeanB2 respectively.
This is what I think @Qualifier and @Resource will be useful for.
Ah. With @Resource you don't also include @Qualifier. @Qualifier is only used with @Autowired. Because @Resource("classB") does the trick. The @Resource ahs an attribute that would be the id for clearing up the ambiguity. I believe I said that in my original post??
Joined: May 16, 2006
I was away for a while...
I agree (do I have a choice ) with what you are saying. My point is
Do these things do the same thing?
1. Use @Resource with name attribute in Java code and use "ref" attribute in bean config file
2. Use @Autowired and @Qualifier in Java code and use "ref" attribute in bean config file
I think cases 1 and 2 do exactly the same thing, which you did say before. I was trying to find a reason why there are 3 options to do the same thing.
The reason I thought was, if there are two beans of the same class, then using annotations in components, we could wire these 2 beans on a component by component basis. Do you think this is logical?
Actually thinking of it, I feel using a different ref value in the config file will also accomplish the same. Now I am confused myself
@Autowired was first before jsr250 common annotation where @Resource came from. Then more recent @Inject in another JSR can to fruition. Spring supports all so that you can take things like EJB3 can use it as is in Spring. And @Inject use Guice configuration/code in Spring.
Joined: May 16, 2006
I am not sure what you said Mark, but looks like Spring is accomodating 10 different things that existed before. Backwards compatibility. Inclusion. Anyways...this wasn't a showstopper for me. I'll consider this resolved. Of course, you are always welcome to comment.