I am wondering how can I use the Instance in JUnit4 with Spring
#Inject
Instance<IMyInterface> interfaces;
If I use
#Inject
List<IMyInterface> interfaces;
It works in Spring but not with CDI.
Also, we can use Provider with both CDI and Spring but it's not Iterable.
The #Inject annotation comes from JSR-330-Dependency Injection for Java. Spring knows this annotation and briefly said, Spring treats it as an alternative to #Autowired. That's it.
However, the Instance is part of JSR 299 - Contexts & Dependency Injection. You can have a look at the definition in CDI specifications.
Spring DI is absolutely different and does not implement JSR-299 (CDI) or any other standard. It does not even have a separate API and implementations and everything is just glued together. Therefore, injecting an Instace is not possible with Spring.
Related
So, pretty straightforward question. Can I mix JEE annotations with Spring annotations on the same project? Are there any known issues with mixing both types of annotations?
For example, #Autowired and #Inject? #Named and #Qualifier?
Should Spring be able to solve injections without issues?
The reason I'm asking this is because I've encountered myself with some legacy code that uses Spring as CDI framework but 60% of the code uses JEE annotations. Some beans, however, are wired using #Autowired, there are also Spring ConfigProperties, etc.
I've already seen some weird behaviour, like classes not being injected, or #Named not being recognized by Spring, etc.
Spring does support CDI annotations, including #Inject, #Named, #Qualifier, ... But it comes with some limitations.
If some class is not injected, or #Named is not recognized, I think it is likely a configuration problem.
I am coming at this question from many years of using spring and just starting to look at JEE7 and CDI.
In the Spring world you have to stick #Component on a bean to turn into spring bean that spring will inject with dependencies but in CDI it seems that there is no equivalent of #Component.
To me CDI seems to imply that every class in my web application will be considered a CDI bean which seems undesirable because I have lot of java classes that are not using injection and I would not want some one to just stick #Inject in those classes and have CDI do its magic.
Two questions:
How to restrict what CDI considers to be a managed bean in a jar file?
What is the benefit for CDI to consider every bean to be a managed bean?
Please see the documentation for bean-discovery-mode in beans.xml. This attribute was only made available in JEE7 and is not available in JEE6.
There are two separate annotations to perform dependency injection by name in Spring, javax.annotation.Resource and javax.inject.Named. The documentation at Spring indicates #Resource should be used for injection by name:
If you intend to express annotation-driven injection by name, do not
primarily use #Autowired, even if is technically capable of referring
to a bean name through #Qualifier values. Instead, use the JSR-250
#Resource annotation, which is semantically defined to identify a
specific target component by its unique name, with the declared type
being irrelevant for the matching process.
The above is a bit confusing, as Spring is only advocating #Resource instead of #Autowired combined with #Qualifer. There is no mention of #Named until later in the documentation.
JSR-250 defines #Resource, whereas JSR-330 defines #Inject and #Named. I know they can be mixed-and-matched within Spring fairly easily. Which JSR to use?
It seems like portability with Guice and CDI would be nice, and hence to use the JSR-330 annotations. On the other hand, the documentation also points out at a couple of limitations within Spring when using JSR-330 annotations.
What is the best practice (if there is one) for annotation injection-by-name?
Thank you.
#Resource is older and is supported since Spring 2.5 while #Named support has been added in Spring 3.0 and both of them can be used to achieve the same purpose of injection-by-name.
When using Spring, my concerns for preferring one over the other would be backward compatibility with Spring 2.5 and whether javax.inject can be added/assumed-to-be on the classpath or not.
It is possible to use Google Guice (any other DI framework) for injecting EJBs in Java EE 5? By default Java EE 5 uses JNDI to injecting EJBs.
I have no direct experience with Guice - but yes, it's possible to use other frameworks for injecting EJBs in a JEE5 application. For instance, Seam does just that. So in principle, it should be possible as there isn't an inherent restriction in the kind of objects that can be injected, as long as the framework takes care of all the lookup details.
UPDATE:
Take a look at this post detailing how to inject EJBs using Guice.
Java EE 6 offers (at least) two Dependency Injection mechanisms: DI annoations from Java EE 5 like #EJB, #PersistenceContext, #Resource ... and the new JSR 330. Can I replace the "old" DI annotations with the more general JSR 330 annotations?
Are there any benefits or drawbacks of the one or other approach? Which one would you use and why?
Go with JSR 330 annotations. They'll work with other DI frameworks that are up to date, like Spring 3.0.
I think JSR330 annotations are the obvious choice. But it's important to realize that JSR-330 only concerns the using of dependencies, not the definitions.
So you'll still be bound to some proprietary format for defining your beans, if this is guice or spring may be up to your preferences. Most of my spring beans are both producing and consuming dependencies, meaning I'm no less independent from spring now that I was before switching to JSR-330.