Re: [jsr-314-open-mirror] [jsr-314-open] [Mojarra-1812-FacesServlet.service] PROPOSAL
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