Java Server Faces Lifecycle

Java Server Faces is a server side MVC based java framework for Web application development. It includes a set of APIs which represent different UI components and helps in managing their states . It helps developers to concentrate on business logic rather than concentrating on common life cycles of Web Applications :

Handling requests , Decoding parameters , Validations , conversions , Modification and saving states and rendering responses to the clients .

JSF request processing lifecycle starts as soon as new HTTP request is submitted by the client to JSF controller servlet . This life cycle consists of six phases . JSF framework manages life cycle phases automatically . Following are the life cycle phases given in the order of execution  :

• Restore view Phase
• Apply request values Phase
• Process validations phase
• Update model values phase
• Invoke application phase
• Render response phase

Generally JSF request processing lifecycle can be divided into two main phases , e.g. , Execution phase and Render phase. Execution phase is further divided into different phases to ease each step of component tree (view) processing like data conversion , validation , event handling , data loading to beans and performing business logic on the data .

Execution of all the six phases for all the requests is not mandatory . Request processing lifecycle can be ended at any of the phases by calling FacesContext.responseComplete() method. We will discuss this kind of situation in later phase. During the lifecycle view must be build while considering the state saved from a previously submitted page. The phases altogether ensures that processing of request follows a logical path .

Lifecycle Phases :

JSF lifecycle phases follows following logical path :

JSF lifecycle

Whenever a request is received , an instance of javax.faces.context.FacesContext is created. The FacesContext object contains all the information related to current request. Basically there are two kind of requests : initial request and postbacks. Initial request occurs when user request for a page for the first time and postback request occurs when user submit a form contained on a page which was loaded on the browser as a result of initial request.

For initial request only Restore view and Render response phases are being executed . All other lifecycles phases are skipped . But for postbacks all the lifecycle phases are being executed as per the preconditions and order.

Usually, the first request for a JavaServer Faces page comes in from a client, as a result of clicking a link or button component on a JavaServer Faces page. To render a response that is another JavaServer Faces page, the application creates a new view and stores it in the javax.faces.context.FacesContext instance, which represents all of the information associated with processing an incoming request and creating a response. The application then acquires object references needed by the view and calls the FacesContext.renderResponse method, which forces immediate rendering of the view by skipping to the Render Response phase of the lifecycle.

Sometimes, an application might need to redirect to a different web application resource, such as a web service, or generate a response that does not contain JavaServer Faces components. In these situations, the developer must skip the Render Response phase by calling the FacesContext.responseComplete method.

The most common situation is that a JavaServer Faces component submits a request for another JavaServer Faces page. In this case, the JavaServer Faces implementation handles the request and automatically goes through the phases in the lifecycle to perform any necessary conversions, validations, and model updates, and to generate the response.

Let’s discuss detail about the lifecycle phases .

• Restore View :

Whenever a request comes to JSF controller , Restore view phase begins . This phase can handle two kind of requests : initial view and postbacks . Restore view phase perform following activities :

• Creates instance of FacesContext which contains all the information of request.
• Creates view of the requested page with view id.
• Wires event handlers to the view.
• Wire validators to the view.
• Save the view to the FacesContext instance using setViewRoot() method.
• Now next phase after Restore view phase is decided depending upon request type . For initial view , controller creates an empty view and framework advances directly to the Render response phase skipping all other phases as there is no user input to process further. For postbacks , controller needs to restore view with current state . Hence framework moves to Apply request values phase.

• Apply Request Values Phase :

There are a set of UI components in the component tree which receive input data from user to process . Hence after completion of Restore view phase , framework moves to Apply request values phase in case of postbacks to process user data further using following steps :

• Iterates over all the components in the component tree and request to decode itself.
• Extract new values from those components using its processDecode() method.
• Values are then stored locally on corresponding components.
• If any decode method calls renderResponse , it skips to render response phase.
• The existing events are broadcasted to the associated event listener .
• Validation , conversion and event associated with the component will be processed if any of the component attribute immediate is set to true . Also if error occurs during validation , error messages are generated and associated to the FacesContext to display at the Render Response phase. Also in that case framework skips to directly Render Response phase .
• Also if application needs to redirect to a different web resource or a response without JSF component , it calls FacesContext.responseComplete() method .
• End of this phase , new values , messages if any are set to components and events have been queued up to FacesContext for further processing.

• Process Validations Phase :

In this phase , the values of components are validated against some predefined validation rules using registered validators of the components by processValidators() method of FacesContext.

• It examines all the local values stored in the components with specified validation rules against JSF standard validators or custom validators whichever is registered .
• Also converts input components for which immediate values are set to false .
• If error occurs during validation , error messages are generated and associated to the FacesContext to display at the Render Response phase. Also in that case framework skips to directly Render Response phase . If there is any error messages from Apply request values phase , those are also displayed.
• If any validate method calls renderResponse , it skips to render response phase.
• Also if application needs to redirect to a different web resource or a response without JSF component , it calls FacesContext.responseComplete() method .
• All the value change events associated with components are fired and used by appropriate listeners .

• Update Model Values Phase :

After the process validation phase if JSF implementation ensures all the local values ( data ) valid :

• It traverses component tree and set all the values of backing bean or model objects are updated with component’s value ( value attribute ).
• If controller fails to convert any component value to the type specified in the bean attribute , framework moves to Render Response phase directly.
• If any updateModels method calls renderResponse , it skips to render response phase.
• Also if application needs to redirect to a different web resource or a response without JSF component , it calls FacesContext.responseComplete() method .
• If everything is fine , we are ready to execute our business logic in next step , Invoke Application phase.

• Invoke Application Phase :

In this phase all the application events are handled . In Apply Request values , controller have added all the events queued to the FacesContext for their further processing in Invoke Application phase.

• Framework broadcasts all the action events which are further handled by registered action event listeners .
• If application needs to redirect to a different web resource or a response without JSF component , it calls FacesContext.responseComplete() method .
• Then JSF tranfers control to the Render Response phase .

• Render Response Phase :

Render Response is the last phase of the framework which is finally responsible for rendering all the response to the client side .

• In case of Initial view request , components that are represented on the page are added to the component tree .
• For postbacks , components are already added to the component tree . Hence all the error messages that have been added during Apply Request Phase , Process Validation Phase or Update Model Values phase are being displayed along with current state of the view .
• The state of the view is saved so that subsequent requests can access that.

Partial processing of request is also possible ,i.e. , a single component or partial component tree can be processed . JSF ajax framework can generate this kind of requests . Partial request enters the JavaServer Faces lifecycle, the information is identified and processed by a javax.faces.context.PartialViewContextobject .