JSF Lifecycle

JavaServer Faces
Copyright Lund & Bendsen A/S

JSF lifecycle
JSF uses a well defined procedure a lifecycle to analyse a request, organize and process its components and underlying model, and send a response. The lifecycle consists of six well defined processes. Each time a user sends a request to a JSF web application one or more of these processes will be invoked. As a JSF developer you can configure which processes should be invoked.

JavaServer Faces
Copyright Lund & Bendsen A/S

JSF-lifecycle phase
response complete faces request response complete

Restore View

Apply Request Values

Process Events

Process Validation

Process Events

response complete

response complete

faces response

Render Response

Process Events

Invoke Application

Process Events

Update Model Values

phase
JavaServer Faces
Copyright Lund & Bendsen A/S

4 Scenarios
Non-Faces Request Non-Faces Response Non-Faces Request Faces Response Faces Request Non-Faces Response Faces Request Faces Response

JavaServer Faces
Copyright Lund & Bendsen A/S

Non-Faces Request Non-Faces Response

A request which does not involve the JSF framework in any way. Not relevant now, so lets move on...

JavaServer Faces
Copyright Lund & Bendsen A/S

Non-Faces Request Faces Response

A request from an external resource not in the JSF framework (e.g. a servlet or external application) to a page in the JSF-framework. This is the case during the first request for a JSF page. The phase Restore View is executed and the component tree of the page is build. Because no changes have been made to the previous component tree (since it does not exist) the next phase will be Render Response, after which the client will receive a response.
JavaServer Faces
Copyright Lund & Bendsen A/S

Faces Request Non-Faces Response

A request from a JSF resource but which returns a response from outside of the JSF framework (e.g. a forward to an external application, a response in the form a PDF, etc.). A resource (component, event handler, validator, etc.) can invoke the method responseComplete() on the FacesContext-object during any of the different phases in the JSF lifecycle. This notifies JSF that a response has been sent to the client. JSF stops all further processing of the lifecycle.

JavaServer Faces
Copyright Lund & Bendsen A/S

Faces Request Faces Response

A request from a page in the JSF framework to another or a postback to the same page. In this case the entire lifecycle is processed (default behaviour). If it is the initial request (the first user request), only Restore View and Render Response will be processed (as explained in scenario 2).
JavaServer Faces
Copyright Lund & Bendsen A/S

Restore View

A view represents all the components on a page (bundled in a component tree). This is represented by an object of type UIViewRoot which is bound to the active FacesContext. This can either be saved client side (in a hidden field) or server side (default). The server saves the view in a session scope, but can persist it to a disc in case of lack of memory or if the user hasnt accessed the page for a long period of time. In the phase Restore View JSF tries to find a view that corresponds to the invoked page. If such a view does not exist a new will be created. The values, event listeners, validators and converters are loaded with their corresponding UI components. In this phase the language settings are initialized. In case of an initial view the created view has no state and JSF skips directly to the phase Render Response. I case of a postback a view will already have been created. JSF uses the state for the existing view to generate its new state and continues to the phase Apply Request Values.

JavaServer Faces
Copyright Lund & Bendsen A/S

Apply Request Values

In this phase JSF makes the view decode the HTTP request getting the HTTP parameters and transferring them to the UI-components in the tree (NOT the managed beans). The view invokes the method decode() on each component. These invokes the method decode() on their child component and so forth. Each component locates its corresponding elemen in the request by comparing IDvalues and replaces the existing value with the new one (using the method setSubmittedValue()). In the meantime the value is converted using the associated Converters getAsObject()-method. If an error occurs during the conversion JSF skips directly to the Render Response-phase and the user is notified of the error. Validation of input parameters are normally done in the next phase (Process Validation). If an input control has its property immediate set to true it will be validated in this phase. Controls which defines buttons and hyperlinks (action sources) also have an immediate-property; if this is true the corresponding action events will be triggered in this phase as well they are normally triggered in the Invoke Application-phase. This is done in case you wish to validate a value without the need for validating the entire component tree.

JavaServer Faces
Copyright Lund & Bendsen A/S

10

Process Validations
In this phase the components new data is validated. JSF will once more let each component validate it self by envoking validate(), which either uses internal logic to validate with or use registered Validators. If a validation failes JSF will save the error messaage and move directly to the phase Render Response, where the user will se the previous page and possibly the error message. Otherwise the components property will be set to true.
JavaServer Faces
Copyright Lund & Bendsen A/S

11

Update Model Values

In this phase the Managed Beans are updated with the information from the component tree. Beans which, using EL, are bound to components will be automatically updated to reflect the components values in this phase. Data in the component tree are expected to be converted and validated at this time. The method processUpdates() is invoked on each component and subcomponents from the view.

JavaServer Faces
Copyright Lund & Bendsen A/S

12

Invoke Application
In this phase ActionEvents are processsed as a response to an invocation of an ActionSource (buttons and links). This means both the action defined as receiver on the page form element as well as potential ActionListeners. If an ActionSource control has its immediate property set to true, it will already have been processed in the phase Apply Request Values. This phase will typically control the page flow. This is done be correlating the result of the action-methods with the navigation rules on the JSF configuration (usually facesconfig.xml). The method for this part of the lifecycle is called processApplication() and is invoked just like the other corresponding methods on the UIViewRoot-object.
JavaServer Faces
Copyright Lund & Bendsen A/S

13

Render Response
In this phase JSF makes the web container create a new response based on the page which the Invoke Applicationphase pointed to. Components on the page are updated using the model and rendered on the page based on their respective Renderers. If an error occurred during the conversion or validation the previous page will be loaded and messages containing error statements will be accessible for <message> / <messages>-tags. The JSF-specification requires that the provider provides a default view handler. This is responsible for generating a response as well as build a view corresponding to the phases Restore View and Render Response. It is possible to provide your own view handler if you would rather not base your JSF application on JSP.
JavaServer Faces
Copyright Lund & Bendsen A/S

14

Life cycle event handling

In each of the four middle phases (Apply Request Values, Process Validation, Update Model Values, and Invoke Application) components can fire one or more events. These events (of the type FacesEvent) is put into a queue on the component with the method queueEvent(). After each phase JSF will invoke the method broadcast() on the component for each event. This invocation ensures that each listener on the component is aware of this event. Listeners will be notified in the order they registered.

JavaServer Faces
Copyright Lund & Bendsen A/S

15

Render Response/Response Complete

A component can at any point of the five first phases invoke the method renderResponse() on the active FacesContext. This makes the framework skip directly to the phase Render Response. The FacesContext has (as previously mentioned) a method called responseComplete(). This terminates the JSF life cycle completely as the framework expects the client has received a response from somewhere else.

JavaServer Faces
Copyright Lund & Bendsen A/S

16