I haven't checked, but why does Faces have to do anything special to handles Session-scoped beans for fail-over? Isn't the application server going to handle this anyway? And if there is a Serialization failure, isn't the user pretty much hosed at this point? In this case, if a fail-over occurred the user would at best lose state. Also, this kind of error is almost certainly an application coding error and there is nothing that the appliction listener can really do that is helpful at this point. If you really feel like publishing the event, how bad would it be to create a one shot FacesContext just for delivering the event and then release it immediately after? -- Blake Sullivan On 9/8/10 9:44 AM, Ed Burns wrote: > Thanks for your prompt response. > > Comments inline. > >>>>>> On Wed, 8 Sep 2010 18:05:15 +0200, Matthias >>>>>> Wessendorf<matzew(a)apache.org> said: > MW> I think I don't get why the release() has been (re)moved at all and > MW> why this now need to exposed as lifecyle API. > MW> Doesn't the ticket talk about exception handling/reporting? I think I > MW> don't understand how that is related to release the facesCtx. > > The reason it impacts exception handling is the case where an exception > is thrown as a result of action taken by the JSF impl to synchronize > session scoped beans at the end of a JSF request so that clustering > requirements are not violated. This is the catch block that needs to be > invoked when such an exception is thrown: > > EB> + } catch (Throwable t) { > EB> + ExceptionQueuedEventContext eventContext = > EB> + new ExceptionQueuedEventContext(context, t); > EB> + context.getApplication().publishEvent(context, > EB> + ExceptionQueuedEvent.class, eventContext); > EB> + context.getExceptionHandler().handle(); > EB> + } finally { > > Obviously, this needs to happen *before* the FacesContext is released. > > This proposal, provides a simple and clean way for the implemention to > know that the jsf portion of the request processing lifecycle has > finished. > > Ed