JSF lifecycle implementation does not conform to JSF specification requirements
-------------------------------------------------------------------------------
Key: WW-1357
URL: http://issues.apache.org/struts/browse/WW-1357
Project: Struts Action 2
Type: Bug
Components: Interceptors
Reporter: Craig McClanahan
Section 11.1 of the JSF specification describes the required processing for
each phase of the request processing lifecycle. The following three bullets,
quoted from the spec, describe the requirements related to calling phase
listeners.
* Call the beforePhase() method of each relevant listener, in the order
that the listeners were registered.
* If no called listener called the FacesContext.renderResponse() or
FacesContext.responseComplete() method, execute the functionality
required for the current phase.
* Call the afterPhase() method of each relevant listener, in the reverse
of the order that the listeners were registered.
In other words, if the beforePhase() method on a phase listener is called, then
the afterPhase() listener must also be called -- whether or not the
functionality specific to this phase is actually executed. This requirement is
violated by the current jsf stack of interceptors, which often call
informPhaseListenersBefore() and then return if certain conditions are met,
without calling informPhaseListenersAfter(). The original MyFaces code from
which these implementations appear to be cut-n-pasted enforced the requirement
by using a try/catch/finally block. Something similar should be done here.
An example of this problem is the following code from
org.apache.struts.action2.jsf.FacesResult in the render() method:
informPhaseListenersBefore(facesContext, PhaseId.RENDER_RESPONSE);
if (isResponseComplete(facesContext, "render", true)) {
return;
}
... perform the rendering logic, possibly throwing an exception ...
informPhaseListenersAfter(facesContext, PhaseId.RENDER_RESPONSE);
In other words, the call to the afterPhase listener will be skipped if
responseComplete is called (by a beforePhase event listener), or if the
rendering code throws an exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira