JSF Life cycle

Let’s understand the life cycle of JSF. A Java Server Faces application supports two kinds of responses and two kinds of requests:
  • Faces response: A servlet response that was created by the execution of the Render Response Phase of the request processing life cycle.
  • Non-Faces response: A servlet response that was not created by the execution of the render response phase. An example is a JSP page that does not incorporate Java Server Faces components.
  • Faces request: A servlet request that was sent from a previously generated Faces response. An example is a form submit from a Java Server Faces user interface component, where the request URI identifies the Java Server Faces component tree to use for processing the request.
  • Non-Faces request: A servlet request that was sent to an application component, such as a servlet or JSP page, rather than directed to a Java Server Faces component tree.

JSF – Lifecycle

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:

JSF – Faces Servlet Snapshot

<!-- 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