I am working on a project that uses a hybrid of JSF and Spring-MVC. User interface endpoints are accessed through a JSF front controller (javax.faces.webapp.FacesServlet), whereas REST service calls are accessed through a Spring-MVC front controller (org.springframework.web.servlet.DispatcherServlet). Deeper layers are Spring-managed (more-or-less). I don't like this arrangement, but I'm not in a position to change it.
The problem is that Spring's request-scoped beans aren't initialized when processing requests that come in through the JSF front controller. Is there an off-the-shelf solution for integrating Spring's WebApplicationContext with the JSF machinery so that the Spring request-scoped beans are initialized for each request regardless of whether that request comes through the JSF or Spring servlet?
There are two ways to integrate JSF with Spring, depending on which framework you want to give most control:
JSF front controller:
One way is to route all requests via the JSF faces servlet and let JSF route them to controllers, let JSF manage navigation state via faces-config. Then inject spring beans into JSF managed beans and access spring beans from the facelets view using value expressions via SpringBeanFacesELResolver.
See this post for a working example.
Spring front controller: put spring as a front controller with a dispatcher servlet and put in place spring webflow. This is the preferred and most powerful way to integrate the two frameworks, see this section of the documentation.
Spring webflow will manage the navigation state and the faces config file is mostly empty. There is no need for the JSF managed beans layer, request get directly handled by webflow.
Actions in JSF buttons trigger webflow transitions directly, and spring beans can also be used in value expressions to build the view. With this solution the integration with Spring is more seamless as webflow offers more possibilities then the JSF navigation mechanism: trigger bean methods between transitions, post redirect get pattern for avoiding double submissions.
Namelly the problem with the initialization of spring request scoped beans is solved with this direction, altough an alternative for this is to add a RequestContextListener OR a RequestContextFilter to web.xml (see section 3.4.4.1 of the docs).
Related
I am having a JSF application and I am using Spring for bean management. I registered all JSF beans as Spring beans and everything was running very smoothly. Now, I have got a requirement to use JSF's view scope, so it means I have to create a JSF managed bean (which I did using JSF annotations and all).
Now, I want to access this JSF bean in a Spring bean, certainly I cannot inject or get it using Spring's application context because Spring container doesn't know about this bean. So, currently in my Spring bean code I am getting this JSF bean using JSF's EL Resolver (examples mentioned here).
What I want to know is that is there any better way to do this?
My application is on Spring 4.0 and JSF 2.0 (MyFaces implementation), please let me know if you need any other information. I have not placed code because all my code is in remote server, moreover I think code is not required for this as there is no debugging over here.
I have fundamental idea about servlet and spring mvc. But I don't know that there is a usage of servlets in spring mvc or not. In spring mvc we have controller classes. My thinking is servlet is used in spring mvc as a controller. If I'm incorrect please correct me.
Yes,you are perfectly right. Servlets are used in Spring-MVC. In Spring-MVC when you write annotation like #Controller, indirectly you are using a Servlet called Dispatcher Servlet. Dispatcher Servlet is defined in web.xml file with properties and class name which is mapped to .jsp pages and Controller part.
Related / Duplicated to When to use Servlet or #Controller. The question is not the same but quite the explanation on that question you will be able to understand:
If you're a student interested in learning the language then I would stick with servlets for now. It's possible to write a web app using just servlets but in practice you'll probably want to look at JSP's too.
A JSP is a convenient way to write a servlet that allows you to mix html with scripting elements (although it's recommended to avoid Java code in your jsp in favour of tags and el expressions). Under the covers it will be compiled as a servlet but it avoids you having to use lots of messy print statements.
It's important to have at least a basic understanding of servlets and JSP's. Spring MVC is one of many frameworks built on top of servlets to try make the task of writing a web application a bit easier. Basically all requests are mapped to the DispatcherServlet which acts as a front controller.
The DispatcherServlet will then call the controller whose annotations match the incoming request. This is neater than having to write these mappings yourself in the web.xml (although with servlet 3.0 you can annotate servlets now). But you also get many other benefits that can be used like mapping form fields to an object, validating that object with jsr303 annotations, map inputs and outputs to xml or json etc etc. Plus it's tightly integrated with core spring so you can easily wire in your services for the controller to call.
It's worth noting that there are a plethora of competing frameworks built on top of servlets. Spring MVC is one of the most popular so it's not a bad choice to look into.
Controllers are not Servlets! Controllers are normal Spring MVC beans that do not extend HttpServlet. Instead what Spring has is a custom extension of HttpServlet called DispacherServlet. Looking at the DispacherServlet's source code you can see that the class hierarchy goes: DispatcherServlet extends FrameworkServlet → FrameworkServlet extends HttpServletBean → HttpServletBean extends HttpServlet.
The DispatcherServlet, like any other Servlet, is declared in the web.xml. It handles all incoming HTTP requests. It is called a front controller which provides a single point of entry in your application. It is responsible for request handling by delegating requests to additional components of Spring MVC controllers which do not extend the HTTP Servlet API.
Look at the following diagram
In this picture DispacherServlet is the only HttpServlet. The Controllers, HandlerMapping and ViewResolver are all Spring MVC beans.
I start to learn spring recently.
My goal is to use spring MVC to do restful api
I know spring MVC is web framework in spring
I know that in spring,there is beans.xml
And in spring MVC , there is servletname-servlet.xml
I want to know where is difference??
Is it means if I use spring MVC,I don't need to use beans.xml??
Please give me some way or give me example project link with spring and spring MVC together
The servletname-servlet.xml defines the beans for one servlet's app context. There can be number of servlets in a webapp and for every servlet we have servletname-servlet.xml (e.g. spring1-servlet.xml for servlet1, spring2-servlet.xml for servlet2).
Beans defined in servletname-servlet.xml can reference beans in beans.xml, but not vice versa.
All Spring MVC controllers must go in the servletname-servlet.xml context.
Beans.xml contain beans that are shared between all servlets in a webapp.Usually the beans.xml context is not necessary if you have only one servlet in your webapp.
You could define all your beans in servletname-servlet.xml but it's not a good practice.
Usually if you create a web application in 'pure' spring (ie. without spring MVC) then you will add ContextLoaderListener as a filter to your web.xml. Then spring will look for applicationContext.xml when you will usually import beans.xml.
In servletname-servlet.xml you define servlets. Servlets can refer other beans. So it's good practice to separate front (servlets) from backend (beans.xml).
Also remember that beans declared in servletname-servlet.xml are overriding the definitions of any beans defined with the same name in the global scope.
See also better answer at: ContextLoaderListener or not?
WI have a question about the "Best Practice" Design for controller beans.
I was reading this very good question and the linking article:
Question "JSF backing bean structure (best practices)"
Scoping Best Practice
Online Article
Distinctions between different kinds of JSF Managed-beans
My question is concerning the controller bean. I'm using JSF / Spring and was wondering why I would want to use request scope for Controller beans?
The controller logic being defined as "...execute some kind of business logic and return navigation outcome.." I would think doesn't require a request scope but either session/application scope. Why keep creating those controller objects on every request?
In my case I would create the controller bean in the faces-config obviously and inject it with my managed properties through spring.
Thoughts please around the scoping? Thanks.
Clarification:
Using JSF 1.2, Spring 3. Using faces-config.xml to declare my beans. Not through annotations.
i have a JSF web application. I use Beans as Spring Beans (not JSF managed beans). Now i have an URL to application www.example.com?parameter=2
I would like to set this parameter into bean on the page load. I now how to do this with spring web flow but with JSF Navigation i cant do this.
What do you think about using JSTL c:set or jsp:setProperty?
Thanks for your help.
Kind regards
Sebastian
From here:
One could extend a Springs org.springframework.beans.factory.config.PropertyPlaceholderConfigurer which accesses the RequestContext (org.springframework.web.context.request.RequestContextHolder#getRequestAttributes()) to resolve ${xyz}-like properties in the bean.
Of course that would only work for Spring beans with “request”-scope.
If the bean is in session-scope you could simply use the following in a Phase Listener method:
property = FacesContezt.getCurrentInstance().getExternalContext
.getRequestMap().get("paramName");
the phase listener is defined with
<f:view beforePhase="#{bean.method}">
if using facelets, its beforePhaseListener
If you were using faces-context.xml, you could've used the <managed-property>.