These different requests and responses result in three possible life cycle scenarios that can exist for a Java Server Faces application:
Scenario 1: Non-Faces Request Generates Faces Response
An example of this scenario occurs when clicking a hyperlink on an HTML page opens a Java Server Faces page. To render a Faces response from a non-Faces request, an application must provide a mapping to FacesServlet, which accepts incoming requests and passes them to the life cycle implementation for processing. Identifying the Servlet for Life Cycle Processing describes how to provide a mapping to the FacesServlet. When generating a Faces response, the application must create a new view, store it in the FacesContext, acquire object references needed by the view, and call FacesContext.renderResponse, which forces immediate rendering of the view by skipping to the Render Response Phase
Scenario 2: Faces Request Generates Non-Faces Response
Sometimes a Java Server Faces application might need to redirect to a different web application resource or might need to generate a response that does not contain any Java Server Faces components. In these situations, the developer must skip the rendering phase (Render Response Phase) by calling FacesContext.responseComplete. The FacesContext contains all the information associated with a particular Faces request. This method can be invoked during the Apply Request Values Phase, Process Validations Phase, or the Update Model Values Phase.
Scenario 3: Faces Request Generates Faces Response
This is the most common scenario for the life cycle of a Java Server Faces application. It is also the scenario represented by the standard request processing life cycle described in the next section. This scenario involves a Java Server Faces component submitting a request to a Java Server Faces application utilizing the FacesServlet. Because the request has been handled by the Java Server Faces implementation, no additional steps are required by the application to generate the response. All listeners, validators and converters will automatically be invoked during the appropriate phase of the standard life cycle, which the next section describes.
FacesServlet : When an event occurs (say, when the user clicks a button), the event notification is sent via HTTP to the server. On the server is a special servlet called the FacesServlet. Each JSF application in the Web container has its own FacesServlet.
For JSF requests to be processed, they must be directed to a servlet called FacesServlet. The redirection is accomplished by using the following servlet and servlet-mapping tags in the deployment descriptor:
<!-- Faces Servlet --> <servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <!-- Faces Servlet Mapping --> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>/faces