JavaServer Faces life cycle

Each JavaServer Faces request that renders a JavaServer Pages (JSP) page involves a JavaServer Faces component tree, also called a view, and goes through a request processing life cycle made up of phases. The standard phases of the request processing life cycle begin with building the restore view, then request values are applied, validations are processed, model values are updated, and the application is invoked.

Build Restore View

The JavaServer Faces component tree is used to build and maintain state and events for the page. The tree is built once per session and reused when users return to the page. At the end of this phase, the root property of the FacesContext instance for the current request reflects the saved configuration of the view generated by the previous Faces Response, if there is one.

Apply Request Values

The purpose of this phase of the request processing life cycle is to give each component the opportunity to update its current value using the information included in the current request, such as parameters, headers, and cookies.

Process Validations

As part of the creation of the view for this request, zero or more validator instances can be registered for each component. In addition, component classes themselves can implement validation logic in their validate() methods. At the end of this phase, all configured validations are completed.

Validations that fail cause messages to be enqueued via calls to the addMessage() method of the FacesContext instance for the current request, and the valid property on the corresponding components are set to false. If any of the validate() methods that were invoked called responseComplete() on the FacesContext instance for the current request, the life-cycle processing of the current request must be immediately terminated. If any of the validate() methods that were invoked called renderResponse() on the FacesContext instance for the current request, control must be transferred to the Render Response phase of the request processing life cycle. The same conditions are true for an event listener that processed a queued event. If none of these conditions occurs, control proceeds to the next phase to update model values.

Update Model Values

If this phase of the request processing life cycle is reached, it means that the incoming request is syntactically and semantically valid according to the validations that were performed, the local value of every component in the component tree has been updated, and it is now appropriate to update the application's model data in preparation for performing any application events that have been queued.

Invoke Application

As described when building a restore view, if the view for the current request was reconstructed from state information saved by a previous request, the JavaServer Faces implementation will have ensured that the ActionListener returned by calling getActionListener on the Application object for this Web application will be registered with all UICommand components in the component tree, by virtue of the restoreState() method.

Render Response

This phase accomplishes two things at the same time: causes the response to be rendered to the client, and causes the state of the response to be saved for processing on subsequent requests. The reason for handling both of these responsibilities in one phase is because the act of rendering the response in JSP applications can cause the view to be built as the page renders. Therefore, the state of the view cannot be saved until after it is rendered to the client.

Event Processing

During several phases of the request processing life cycle, events can be queued, for example, via a call to the queueEvent() method on the source UIComponent instance, or a call to the queue() method on the FacesEvent instance. These queued events must now be broadcast to interested event listeners. The broadcast is performed as a side effect of calling the appropriate life-cycle management method (processDecodes(), processValidators(), processUpdates(), or processApplication()) on the UIViewRoot instance at the root of the current component tree. For each queued event, the broadcast() method of the source UIComponent will be called to broadcast the event to all event listeners who have registered an interest on this source component for events of the specified type. A Boolean flag is returned indicating whether this event has been handled completely and whether the JavaServer Faces implementation can remove it from the event queue.

It is also possible for event listeners to cause additional events to be queued for processing during the current phase of the request processing life cycle. Such events must be broadcast in the order they were queued after all originally queued events are broadcast, but before the life-cycle management method returns.

See the API reference for the UIComponent.broadcast() method for the detailed functional requirements.

 

Related concepts

JavaServer Faces

 

Related tasks

Creating Faces applications - overview
Creating a Faces JSP page

Related reference
Faces components reference
Attributes for Faces components