[jsr-314-open-mirror] [jsr-314-open] [Mojarra-1512-FacesServlet.service] PROPOSAL

[Ed Burns]

>>>>> On Wed, 08 Sep 2010 09:37:27 -0700, Blake Sullivan <blake.sullivan at oracle.com> said:

B>   I agree.  It isn't clear how this is the best solution to the problem 
B> logged.

The initial problem for issue 1512 (not 1812 as I incorrectly included
in the subject line) was that an exception was not being sucked in by
the JSF ExceptionHandler.  

The cause is the use of ServletRequestListener.requestDestroyed() to
perform the action that caused the exception.
ServletRequestListener.requestDestroyed() is called *after* the
FacesContext is released, and therefore the ExceptionHandler can't
possibly be used.  

The first iteration of the fix for 1512 was to defer the release of the
FacesContext to the requestDestroyed() implementation.  This has been
shown to be incorrect.  

The second iteration (just suggested today) was to add API that allows
the action to be taken at the right time by the implementation.

Your comments have now alerted me to the existence of another approach:
simply perform this action *in* the implementation's
FacesContext.release() method.  

One problem with this approach, however, is that decorated FacesContext
instances, such as in the portlet case, may completely override
FacesContext.release(), and therefore break clustering, and also not
solve the intial problem of 1512.

Any other ideas?  Should we just do it at the end of Lifecycle.render()?

[1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1512
-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
|  0 work days until JSF 2.1 Milestone 5
|  8 work days until handoff of JSF 2.1 change log to jcp
|  7 work days until JavaOne 2010
| 42 work days until DOAG 2010
| 46 work days until JSF 2.1 Milestone 6