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(a)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