Can I use #Inject annotation in my Spring application, when I will deploy my application in Appserver that doesn't support Java EE 6?
#Inject is introduced in Java EE6 and it doesn't supported by Java EE 5
When you use #Inject in components managed by Spring (Spring beans) its functionality is implemented by Spring, therefore you don't need anything else to make it work.
#Inject support in JavaEE 6 is about components managed by application server (EJBs, etc).
Spring has a synonymous #Autowired annotation that has the same effect. Since it's provided by Spring itself, it should be available on any version of Java that supports annotations.
JSR 330's #Inject annotation can be used in place of Spring's #Autowired in the examples below. #Inject does not have a required property unlike Spring's #Autowire annotation which has a required property to indicate if the value being injected is optional. This behavior is enabled automatically if you have the JSR 330 JAR on the classpath.
spring documentation......
http://static.springsource.org/spring/docs/3.0.0.RC2/reference/html/ch03s09.html
In short, you can. If you are using Spring (>= version 3), Spring will perform its dependency injection base on the #Inject annotations of its beans.
In long, it all depends on what do you mean by "Can be used". Annotation is nothing but a meta data. No one stop you from using #Inject to perform a totally irrelevant function, as long as you inspect the annotation and do whatever you want
Related
Is it possible to intergrate Spring in JAX-RS-API? We wan't use no implementation of JAX-RS (no imports of Jersey, CXF, etc. in our Java code)
Yes it's possible.
You will define #Path and #Component with jax-rs import.
You will define #Controller with Spring annotation.
The link between both will be made by the applicationContext or by annotation.
So, in my opinion yes, you can.
Is there a Java EE 6 / 7 equivalent annotation for Spring's #Configuration?
If the answer is yes then are the equivalents for its surrounding annotations, such as #ComponentScan and #EnableWebMvc?
I did, of course, look for it in Java EE 6 / 7 (I admit I skipped a paragraph here and there), in javadocs (specifically among annotations), in Spring doc, tutorials, blogs, SO and Google.
JEE CDI has also an annotation of creating bean programmatically and exposing them, so it offers bean factories, called producers:
https://dzone.com/articles/cdi-and-the-produces-annotation-for-factory
CDI offers Producer methods (annotated with #Produces) which is the equivalent of #Bean in spring. You can than implement Producers classes that are beans which contain a bunch of producer methods. However, this is by far not as powerful as a spring configuration since as far as I am aware of, there is no possibity to e.g. "import" other configurations (producer classes).
This makes it especially difficult to test CDI applications.
You can either
heavily use mocks to test a single CDI bean to totally avoid injected objects
blow up your test class just to create the instance under test with all dependencies
use testing frameworks like CDI-Unit that creates the beans for you
With 1. Test Driven Development becomes almost impossible and tests have always to be adapted when implementation changes, even if the contract does not change.
With 2. you end up in a lot compiler errors in tests as soon as dependencies between your Beans change
With 3. you need to point your testing framework to the implementation of your beans. Since there exists no Configuration that knows about all beans, the test needs to know about it. Again, if things change your tests will break.
I admit... I don't like CDI ;-P
The javax.servlet.annotation package defines a number of annotations to be used to register Servlet, Filter, and Listener classes as well as do some other configuration, for example, security.
You can also use the ServletContainerInitializer class to configure your ServletContext through Java instead of through the XML deployment descriptor. Spring provides its own implementation of ServletContainerInitializer in which case all you have to do is create a class that implements WebApplicationInitializer and does servlet, filter, and listener registration and leave that class on the classpath.
Examples abound in the javadoc.
What is the equivalent of Guice's #ImplementedBy annotation in Spring DI? (I googled it but with no results.)
There is not exist JIT default binding in Spring. You can set only one implementation to dependency or use naming qualifier #Named or #Qualifier annotation to specify implementation but this is static binding (not equivalent to #ImplementedBy Guice implementation).
I created a spring extension enabling the jit-binding. this library add #ImplementedBy annotation to Spring. See https://github.com/devacfr/spring-implementedby and give me feedback
You can use the annotation #Qualifier
http://static.springsource.org/spring-framework/docs/3.2.0.M2/api/org/springframework/beans/factory/annotation/Qualifier.html
What is the best way to enable injection of spring beans into Jersey 2? Jersey seems to not support this natively.
What is needed to wire the 2 frameworks together? In pom.xml and web.xml?
Jersey 2.3 has now spring support:
https://jersey.github.io/documentation/latest/user-guide.html#spring
As stated in the documentation
The Spring extension module configuration is based on annotations
So you have to tell spring to scan your classpath, for example:
<context:component-scan base-package="my.package.to.resources">
and annotate your resource class with a spring annotation (I advise to use #Component, and then specify the jersey resource scopes #Singleton/#PerLookup/#RequestScoped )
#Component
#Singleton
#Path("example")
public class Example {
//Spring beans can't be injected directly into JAX-RS classes by using Spring XML configuration
#Autowired
private MyOtherBean myOtherBean;
#GET #Path("hello")
public String hello() {
return myOtherBean.hello();
}
}
As of June 2013, Jersey 2.0 has no official Spring support. There are two options:
Use third party code from here https://github.com/marko-asplund/jersey/tree/master/ext/jersey-spring
Wait until HK2 spring bridge becomes stable and documented https://java.net/jira/browse/HK2-40
See also:
http://jersey.576304.n2.nabble.com/Spring-framework-support-for-Jersey-2-td7580673.html
EDIT: Jersey 2.3 has spring support now, see the answer by Fabio below
You should be able to annotate jersey components and then use annotations to inject the beans.
#Service //(or #Component)
public class MyJerseyService {
#Autowired
private MyObj mySpringBean
}
I would like to achieve this idealism :
To have only 1 implementation for the JSF Bean container, like to use only Spring or Weld but not both. Currently i am using Spring for my backend, so i prefer Spring.
To have only 1 annotation, to choose between #ManagedBean, #Named, #Model
To be able to use all supported scopes, like #RequestScoped, #SessionScoped, #ViewScoped, #FlashScoped, maybe also #ConversationScoped
The JSF Beans could be injected with spring-managed-services (The backend services), perhaps using #Inject or #Autowired
So far i've been finding no best combination to achieve these because as far as i know, please correct me if i am wrong, :
#ManagedBean can not be injected with spring services ?
#Named can be injected with spring services using #Inject, but #Named is using Weld. Can i just use spring to managed the #Named instead of Weld ?
#Named doesnt support #ViewScoped and FlashScope ?
Please share your thoughts and experiences.
Thank you :-)
UPDATE 15 March 2011
Found an interesting page that describes how to replace Jboss Weld with Spring as the JSR 299 CDI implementation. So basically, the question number 2 is answered. Number 1 is also answered indirectly since i can now inject spring services.
But still, the number 3 question remains. I would find very helpful if i can use the #ViewScoped and Flash Scope in the #Named, something like this article. Flash scope implementation has yet to be seen, but the closest one i can get so far is this page.
Hopefully, replacing weld with spring as the jsr 299 implementation will still enable me to use #ConversationScoped.
Gotta test things now, wish me luck :-)
UPDATE 18 MARCH 2011
Successfully make use of Spring 3 instead of weld to do the #Named, #Inject. The important thing is to set the el-resolver in the faces-config.xml.
AFAIK, Spring 3 currently doesnt support CDI yet, so bye2 #ConversationScoped.
For the scoping, i must still use #Scope("request") or #Scope("session"), but if i prefer the #RequestScoped (javax.enterprise.context.RequestScoped) and #SessionScoped, i can make use of the bridge provided from this article.
The Scope("view") for spring from this article works like magic :-)
One problem remain though, how to pass objects between Scope("view")-beans ..
Wish me luck !
update
Ahhh .. finally done ..
Passing the variables using Flash provided by JSF2 really works like magic.
I dont need an 3rd party implementation for that.
So basically, i can do without weld, but with spring, with the common scopes available, including the view scope, dan can pass between beans using the flash object.
One thing missing is the conversation scope, which isnt a major problem to me yet.
Hopefully the future spring can support this conversation scope.
Cheers :-)
I can successfully Inject Spring bean using ManagedProperty annotation like below. This is on JSF Managed Bean. Spring bean is for backend and I prefer spring for backend.
#ManagedProperty(name="userRepository", value="#{userRepository}")
private UserRepository userRepository;
//Setter and/or Getter
value is the most important thing here. It's actually the bean name of spring. I hope this helps.
Weld (actually, the reference implementation of JSR-299 Context and Dependency Injection, also known as Java EE 6 CDI) was less or more invented to supplant Spring in Java EE 6 environments. I would suggest to use Java EE 6 CDI instead of Spring. Why would you use a 3rd party framework when Java EE 6 provides the same functionality out the box?
If the Spring backend really cannot be changed, then I'd suggest to stick to it and not to intermix with Java EE 6 CDI annotations to save yourself from confusions and maintenance headache.