TL;DR: How do I autowire an EJB into a Spring #Controller??
I'm trying to add a new Spring 4 webapp into a legacy system that currently uses EJBs, and runs in Resin 4. All EJBs are Stateless, and Local, and all contain:
#Resource
SessionContext ejbContext
EJBs are looked up via a singleton that contains the line:
return new InitialContext().lookup("production/entapp/default/myapplication/" + className + "/local");
I've got no experience of using EJBs other than via this method, so I'm not too familiar with how the lookup is performed, only that all the EJBs are found in this manner.
My question:
How do I autowire an EJB into a Spring #Controller??
I suspect I need to create an Interceptor of some kind, that will perform this lookup when it finds the need to autowire an EJB, but having looked through pages and pages of Google and SO, I'm none the wiser.
It's also worth mentioning that I'm trying to do all of this without any XML, using a Java #Configuration class.
Related
I am trying to understand Spring Framework more what I know currently, and I am referring to "Pro Spring 3" book.
I came across the following section in the book as below:
It says that in general IoC can be decomposed into two components viz:
Dependency Injection and Dependency Lookup.
With respect to this, I have following questions:
1) Do Spring provide both Dependency Injection ,Dependency Lookup ?
2) Do all Ioc container have both these systems viz: Dependency Injection ,Dependency Lookup?
3) If Spring provides both Dependency Injection ,Dependency Lookup, then isn't it wrong to say that Spring is DI framework, when it has both these capabilities?
1: Yes, Spring provides both dependency injection and dependency lookup. You can let Spring inject dependencies using for example the #Autowired annotation, and you can also manually lookup components from Spring's ApplicationContext by calling one of the getBean methods.
The main thing to understand about the concept "inversion of control" (IoC) is that Spring does the work for you, instead of the other way around: you let Spring create instances of your components, and you let Spring inject the dependencies, instead of the other way around, where you write code yourself to create instances and lookup dependencies.
2: No, not necessarily.
3: Spring can do dependency injection (DI), so it is a DI framework. Just because it also does other things (such allow you to lookup components explicitly) doesn't suddenly not make it a DI framework anymore.
I have a web project, and I depoly it on tomcat easily. Infact I have a WebAppInitializer class that implements WebApplicationInitializer (this class it's really fat), as you know every application server that supports servlet 3.0, it can easily detect it and try to boot it. Now I wonder that it could be possible to use spring boot starter and without any further configuration, I pass my WebAppInitializer to it and spring boot based on my WebAppInitializer boots my project?
I just want to use the approach of spring-boot to deploy application on Tomcat and I don't want to use other spring-boot's facilities.
Yes, it's an old question. But I do not see an accepted answer and the one closest to a working one only has a link to an external resource. So here it is.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-embedded-container-context-initializer
28.4.2 Servlet Context Initialization
Embedded servlet containers do not directly execute the Servlet 3.0+
javax.servlet.ServletContainerInitializer interface or Spring’s
org.springframework.web.WebApplicationInitializer interface. This is
an intentional design decision intended to reduce the risk that third
party libraries designed to run inside a war may break Spring Boot
applications.
If you need to perform servlet context initialization in a Spring Boot
application, you should register a bean that implements the
org.springframework.boot.web.servlet.ServletContextInitializer
interface. The single onStartup method provides access to the
ServletContext and, if necessary, can easily be used as an adapter to
an existing WebApplicationInitializer.
Scanning for Servlets, Filters, and listeners
When using an embedded
container, automatic registration of classes annotated with
#WebServlet, #WebFilter, and #WebListener can be enabled by using
#ServletComponentScan.
[Tip] #ServletComponentScan has no effect in a standalone container,
where the container’s built-in discovery mechanisms are used instead.
I've tried it. It works
In my use case I have project containing a few dozens of webapps, designed to run on Tomcat as WAR. Lots of logics was neatly crafted into WebApplicationInitializers and it seemed there should be an easier way to reuse all this. Adding implements ServletContextInitializer to those initializers and exposing them as beans through #Configuration classes lit my webservers up with SpringBoot's embedded Tomcat.
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-create-a-deployable-war-file describes precisely how to do it
From the Spring Boot docs:
Servlet 3.0+ applications might translate pretty easily if they already use the Spring Servlet 3.0+ initializer support classes. Normally all the code from an existing WebApplicationInitializer can be moved into a SpringBootServletInitializer. If your existing application has more than one ApplicationContext (e.g. if it uses AbstractDispatcherServletInitializer) then you might be able to squash all your context sources into a single SpringApplication. The main complication you might encounter is if that doesn’t work and you need to maintain the context hierarchy. See the entry on building a hierarchy for examples. An existing parent context that contains web-specific features will usually need to be broken up so that all the ServletContextAware components are in the child context.
So yes, it's possible but you need to convert it to SpringBootServletInitializer, which seems to be quite similar.
This text is from the book called Core Java Server Faces:
It is a historical accident that there are two separate mechanisms,
CDI beans and JSF managed beans, for beans that can be used in JSF
pages. We suggest that you use CDI beans unless your application must
work on a plain servlet runner such as Tomcat. The source code for the
book comes in two versions, one with CDI beans (for Java EE 6
application servers) and one with JSF managed beans (for servlet
runners without CDI support).
My question is:
If I use the Spring Framework, and a Tomcat Server, will I need to use one of the beans mentioned above, or does Spring Framework come with its own bean implementations?
As far as I know, Spring Framework supports Dependency Injection. Does it support it if I run the application on Tomcat? Does it mean that I will be using neither the CDI beans nor the JSF Managed means mentioned in this book?
Thank you.
talking about container is more correct than bean implementation. Yes Spring comes with its own container. In fact you can see spring frameworks as a kind of alternative to the full Java EE stack.
Using Spring DI and CDI together has about no interest but you still can use JSF with spring on tomcat although if i would advise you to switch to a Java EE 6 web profile server instead of spring in this case.
Spring comes with is own view framework implementation named spring mvc.
All of this can run perfectly on any servlet container (jetty tomcat etc...) on condition that you provide associated dependencies ofc.
I understand that Spring has really nice features, such as dependency injection. I am new to Spring. I have understood that I can use Spring alongside with struts and other frameworks too, in order to use its capabilities.
In my project I am going to use Seam 2.0, I am using JNDI to lookup for the EJBs. I am wondering if I can integrate Spring with Seam and use its ApplicationContext in order to get beans from that directly and not use JNDI lookup anymore?
There is a whole chapter in the Seam reference dedicated to this:
27. Spring Framework integration
Spring has support for injecting javax.ejb.EJB annotations, much like it injects #Autowired and other jsr-220 injection annotations, thanks to the CommonAnnotationBeanPostProcessor class.
However, injection doesn't work for servlets, since the servlet isn't created by spring.
This article - Spring injects servlets too - doesn't give an example using servlets, but claims it's possible using compile-time weaving of aspects. Unfortunately, compile-time weaving is not an option for us. Is it possible to do this at runtime? It's ok to introduce a subclass to the servlet if that helps, but I want to keep EJB annotations so the servlets can still deployed in a Java EE container.
EDIT: The app will be deployed to a Java EE container in production, but I was thinking of using spring for running functional tests and for local deployment for development to take advantage of hot JSP loading in Tomcat.
You will need Java EE container like in Glassfish that supports injection of EJBs and beware that injection works on managed classes like servlets, managed beans..etc (classes that are managed by containers) so ejb injection in normal classes would require you to use lookups instead.