JSF 2 Global exception handling, navigation to error page not happening
It's most likely because the current request is an ajax (asynchronous) request. The exception handler which you've there is designed for regular (synchronous) requests.
The proper way to change the view in case of an ajax exception is as follows:
String viewId = "/error.xhtml";
ViewHandler viewHandler = context.getApplication().getViewHandler();
context.setViewRoot(viewHandler.createView(context, viewId));
context.getPartialViewContext().setRenderAll(true);
context.renderResponse();
This is however somewhat naive. This won't work if the ajax exception is been thrown in midst of rendering of a ajax response.
I'd suggest to not reinvent the wheel. The JSF utility library OmniFaces has a complete working solution in flavor of FullAjaxExceptionHandler
. You can find the full source code here and the showcase example here. It makes use of standard servlet API <error-page>
declarations in web.xml
. This way the error pages are also reusable for synchronous requests, with a little help of FacesExceptionFilter
, also provided by OmniFaces.
See also:
- using ExternalContext.dispatch in JSF error handler causes corrupt page rendering
- What is the correct way to deal with JSF 2.0 exceptions for AJAXified components?
user1722908
Updated on July 19, 2022Comments
-
user1722908 almost 2 years
I am developing a JSF 2.0 based web application. I am trying to implement a global exception handler which will redirect the user to a generic error page whenever any exception occurs (e.g. NullPointerException,ServletException,ViewExpiredException etc.)
Whenever a NPE occurs in my app, My customnavhandler breakpoint is hit and NavigationHandler code is executed, but somehow redirection to error page is not happening, the requested page remains partially rendered. Any idea what could be wrong here ? One info is that I am throwing an NPE deliberately on the requested page (which was partiallyu rendered after NPE)
My faces-config.xml entry
<factory> <exception-handler-factory> com.common.exceptions.CustomExceptionHandlerFactory </exception-handler-factory> </factory>
My CustomNavHandler
public class CustomExceptionHandler extends ExceptionHandlerWrapper { private static final Logger logger = Logger.getLogger("com.gbdreports.common.exception.CustomExceptionHandler"); private final ExceptionHandler wrapped; public CustomExceptionHandler(ExceptionHandler wrapped) { this.wrapped = wrapped; } @Override public ExceptionHandler getWrapped() { return this.wrapped; } public void handle() throws FacesException { final Iterator<ExceptionQueuedEvent> i = getUnhandledExceptionQueuedEvents().iterator(); while (i.hasNext()) { ExceptionQueuedEvent event = i.next(); ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource(); // get the exception from context Throwable t = context.getException(); final FacesContext fc = FacesContext.getCurrentInstance(); final ExternalContext externalContext = fc.getExternalContext(); final Map<String, Object> requestMap = fc.getExternalContext().getRequestMap(); final ConfigurableNavigationHandler nav = (ConfigurableNavigationHandler) fc.getApplication().getNavigationHandler(); //here you do what ever you want with exception try { //log error ? logger.error("Severe Exception Occured"); //log.log(Level.SEVERE, "Critical Exception!", t); //redirect error page requestMap.put("exceptionMessage", t.getMessage()); nav.performNavigation("/TestPRoject/error.xhtml"); fc.renderResponse(); // remove the comment below if you want to report the error in a jsf error message //JsfUtil.addErrorMessage(t.getMessage()); } finally { //remove it from queue i.remove(); } } //parent hanle getWrapped().handle(); } }
My customNavhandler factory
public class CustomExceptionHandlerFactory extends ExceptionHandlerFactory { private ExceptionHandlerFactory parent; public CustomExceptionHandlerFactory(ExceptionHandlerFactory parent) { this.parent = parent; } @Override public ExceptionHandler getExceptionHandler() { return new CustomExceptionHandler (parent.getExceptionHandler()); } }
-
BalusC about 9 yearsThis approach has 2 major problems: 1) Error page becomes idempotent (its URL gets reflected in browser address bar and this would not work for error pages placed in
/WEB-INF
for security reasons). 2) Request attributes are lost (along with exception detail). -
Oleksandr Tsurika about 9 yearsImho, there is no sense to show information about NullPointerException, ViewExpiredException or ServletException to user. Thus to use one general error page (idempotent) seems enough. Also seems no much sense to hide error page into WEB-INF. Developer should look logs for exception details . Such approach fully satisfy my current project requirements. But possibly won't satisfy yours... But it does not meen the approach is bad.
-
BalusC about 9 yearsIt's at least not the way how standard Servlet API
<error-page>
work which would make them unreusable in JSF ajax requests.