JSF Life Cycle

JSF has the following phases in request processing life cycle.

1. Restore View Phase 

2. Apply Request Values Phase 

3. Process Validations Phase 

4. Update Model Values Phase 

5. Invoke Application Phase 

6. Render Response Phase 

Life cycle involves only restore view and render response phases for initial requests and the life cycle handles all of the phases for postback requests. Initial request (e.g. HTTP GET) is the request that is made from a browser in order to display a page. Postback happens when the browser posts the page back to the server with form values, etc. Initial request is created by clicking a link, pasting an URL in address bar, while a postback request is created by posting a form by clicking a submit button or any post request.

Restore View Phase

When a request for a JSF facelet is made, such as when a link or a button is clicked, the JSF implementation begins the restore view phase. After receiving the request FacesServlet checks for the view id associated with the current request. If view ID is found then respective component tree used for the request and phase 2 (Apply Request Values Phase) will be started. If no view ID is associated with the request then JSF will carry out the below following steps to form the new component tree and view for the request.

• UIViewRoot object will be created with new view ID and will be stored in FacesContext. 

• Component Tree will be created will be stored in FacesContext. 

• Converters, Validators and listeners will be registered with the components. 

• Managed Bean will be instantiated. 

Apply Request Values Phase

 After the component tree is restored, each component in the tree extracts its new value from the request parameters by using its decode method. The value is then stored locally on the component.

 All the converters which are registered with the individual components of the component tree will be invoked and data conversion will be done.

 If the conversion of the value fails, an error message associated with the component is generated and queued on FacesContext. This message will be displayed during the render response phase, along with any validation errors resulting from the process validations phase.

Process Validations Phase

 All the validators which are registered with the individual components of the component tree will be invoked and input validation will be processed.

 If validation fails an error message is added to the FacesContext instance, and the life cycle advances directly to the render response phase so that the page is rendered with error messages. If there were conversion errors from the apply request values phase, the messages for these errors are also displayed.

 If conversion and validation is successful without any error messages the Update Model Values phase will be started.

Update Model Values Phase

 All the values of individual components of the component tree will be retrieved and will be set to corresponding fields of the managed bean by using setter methods.

 If bean property type does not match with the values from component of the component tree or if no setter methods available from managed bean then life cycle advances directly to the render response phase so that the page is re-rendered with errors displayed. This is similar to what happens with validation errors.

Invoke Application Phase

 FacesServlet invokes the managed bean action methods in response to application-level events, such as submitting a form or linking to another page.

 Managed Bean method with the help of backing bean interacts with model layer and database layer. After complete execution, action method will return the view name in string format.

 NavigationHandler will receive return value from action method and renders correct facelet.

Render Response Phase

 The component tree will be converted to format (html, wml etc.) provided by the rendered kit.  JSF uses by default HTML render kit, if needed to provide the different response for different clients like mobile you have to specify the render kit.

 After the content of the view is rendered, the state of the response is saved so that subsequent requests can access it and it is available to the restore view phase.