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.