Prior to the commit that fixed
FACES-2929, ExceptionHandlerFactoryBridgeImpl.getExceptionHandler() was calling facesContext.getPartialViewContext().isAjaxRequest() in order to determine whether or not the factory should decorate the exception handler.
However, the commit caused a regression such that the ICEfaces ace:fileEntry component stopped working.
It turns out that ICEfaces had a bug in its FileEntryUpload.java class such it was not adding URL parameters to the ExternalContext request parameter map. Because of this, it was not adding the "_jsfBridgeAjax=true" URL parameter. Consequently, the Bridge's RequestHeaderValuesMap was not adding the "FacesRequest=partial/ajax" request header which in turn caused ICEfaces to not recognize the file upload as occurring during an XHR.
The reason why ace:fileEntry worked prior to the commit that fixed
FACES-2929 was because facesContext.getPartialViewContext() was being called when the FacesContext was being initialized (prior to the JSF lifecycle executing). By calling facesContext.getPartialViewContext() at this early point in request processing, the ICEfaces FileEntryUpload.java class was not yet introduced into the execution flow. The RequestHeaderValuesMap class would properly detect the "_jsfBridgeAjax=true" URL parameter and add the "FacesRequest=partial-ajax" header.
So the problem only manifests itself when the call to facesContext.getPartialViewContext() happens later (such as during execution of the JSF lifecycle). At that point, the ICEfaces FileEntryUpload.java class is introduced into the execution flow and will not return the value of the "_jsfBridgeAjax" URL parameter.
Although the bug was fixed in ICEfaces 4.2 via ICE-11253, older versions of ICEfaces require a workaround.