My previous entry dove under the covers for JSF 2.0 and examinedcomposite component metadata. This one is far less esoteric and shows how to handle the ViewExpiredException using a new JSF feature, the ExceptionHandler, contributed byPete Muir a JSF Expert Group representative from JBoss.

JSF throws a ViewExpiredException when a postback is made to a view and, for whatever reason, that view cannot be restored. Usually this is due to a session timeout, but a custom state management solution could also cause this exception to be thrown. The default behavior in JSF2 is to show the Facelets error page saying View Expired. The default page is illustrated at right.

The default ViewExpiredException error page 

One way to fix this is to declare an<error-page> element in your web.xml, as shown here.

  1.     <error-page>
  2.         <exception-type>javax.faces.application.ViewExpiredException</exception-type>
  3.         <location>/faces/viewExpired.xhtml</location>
  4.     </error-page>
  5.  

This works well enough. You can even put JSF components on the error page if you put the proper Faces Servlet mapping in the<location> element, as shown above. If you want to do some application level manipulation in response to the exception, you'll want something different, however. In this case, a custom ExceptionHandler is just the trick. I cover this in much more detial in my upcoming book, JavaServer Faces 2.0: The Complete Reference, and the example shown in this blog entry is neatly integrated into the chapter 10 sample app. Consider this blog entry an appetizer. So delete that old web.xml (it's not needed if you have JSF2 and Servlet 3, which you get in Glassfish V3) and let's go.

First, we need to install a customExceptionHandler. This is done using the tried and true JSF decorator pattern. In this case, we place the following into the faces-config.xml. There's no annotation for this because it's relatively uncommon, and we expect advanced users to use the feature. Therefore, the EG tradeoff was to not add yet another "scan for this annotation" clause to the spec.

  1.   <factory>
  2.       <exception-handler-factory>com.sun.faces.ViewExpiredExceptionExceptionHandlerFactory</exception-handler-factory>
  3.   </factory>
  4.  

Here's the code for the class.

  1. packagecom.sun.faces;
  2.  
  3. importjavax.faces.context.ExceptionHandler;
  4. importjavax.faces.context.ExceptionHandlerFactory;
  5.  
  6. publicclassViewExpiredExceptionExceptionHandlerFactory extendsExceptionHandlerFactory {
  7.  
  8.     privateExceptionHandlerFactory parent;
  9.  
  10.     publicViewExpiredExceptionExceptionHandlerFactory(ExceptionHandlerFactory parent) {
  11.         this.parent = parent;
  12.     }
  13.  
  14.     @Override
  15.     public ExceptionHandler getExceptionHandler() {
  16.         ExceptionHandler result = parent.getExceptionHandler();
  17.         result = newViewExpiredExceptionExceptionHandler(result);
  18.  
  19.         return result;
  20.     }
  21.  
  22.  
  23. }

The interesting things happen on lines 15 - 20. This method is called once per request must return a newExceptionHandler instance each time it's called. I know the method name should becreateExceptionHandler, but we stuck with "get" for consistence with other JSF methods. On line 17, we call the real ExceptionHandlerFactory and ask it to create the instance, which we then wrap in our customViewExpiredExceptionExceptionHandlerFactory class. This is where the real interesting stuff happens.

  1. packagecom.sun.faces;
  2.  
  3. importjava.util.Iterator;
  4. importjava.util.Map;
  5. importjavax.faces.FacesException;
  6. importjavax.faces.application.NavigationHandler;
  7. importjavax.faces.application.ViewExpiredException;
  8. importjavax.faces.component.UIViewRoot;
  9. importjavax.faces.context.ExceptionHandler;
  10. importjavax.faces.context.ExceptionHandlerWrapper;
  11. importjavax.faces.context.FacesContext;
  12. importjavax.faces.event.ExceptionQueuedEvent;
  13. importjavax.faces.event.ExceptionQueuedEventContext;
  14.  
  15. publicclassViewExpiredExceptionExceptionHandler extendsExceptionHandlerWrapper {
  16.  
  17.     privateExceptionHandler wrapped;
  18.  
  19.     publicViewExpiredExceptionExceptionHandler(ExceptionHandler wrapped) {
  20.         this.wrapped = wrapped;
  21.     }
  22.  
  23.     @Override
  24.     public ExceptionHandler getWrapped() {
  25.         return this.wrapped;
  26.     }
  27.  
  28.     @Override
  29.     public void handle()throwsFacesException {
  30.         for (Iterator<ExceptionQueuedEvent> i = getUnhandledExceptionQueuedEvents().iterator();i.hasNext();){
  31.             ExceptionQueuedEvent event = i.next();
  32.             ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource();
  33.             Throwable t = context.getException();
  34.             if (t instanceofViewExpiredException) {
  35.                 ViewExpiredException vee =(ViewExpiredException) t;
  36.                 FacesContext fc =FacesContext.getCurrentInstance();
  37.                 Map<String, Object> requestMap = fc.getExternalContext().getRequestMap();
  38.                 NavigationHandler nav =
  39.                         fc.getApplication().getNavigationHandler();
  40.                 try {
  41.                     // Push some useful stuff to the request scope for
  42.                     // use in the page
  43.                     requestMap.put("currentViewId", vee.getViewId());
  44.  
  45.                     nav.handleNavigation(fc, null, "viewExpired");
  46.                     fc.renderResponse();
  47.  
  48.                 } finally {
  49.                     i.remove();
  50.                 }
  51.             }
  52.         }
  53.         // At this point, the queue will not contain any ViewExpiredEvents.
  54.         // Therefore, let the parent handle them.
  55.         getWrapped().handle();
  56.  
  57.     }
  58. }
  59.  
  60.    
  61.  

On line 15, you see we take advantage of thejavax.faces.context.ExceptionHandlerWrapperconvenience class. JSF has lots of these wrapper classes and when you use them, you need only override the getWrapped()method to return the instance of the class you're wrapping, which is often simply passed to the constructor, as shown on lines 19 - 21. Once you override getWrapped(), you need only override those methods you're interested in. In this case, we want to override only handle(), which we do on lines 29 - 57.

We iterate over the unhandler exceptions using the iterator returned fromgetUnhandledExceptionQueuedEvents().iterator(), as shown on line 30. The ExeceptionQueuedEvent is aSystemEvent (also described in detail in my book) from which we can get the actual ViewExpiredException, which I do on line 35. I know I'm going to be ultimately showing a JSF page so I want to extract some information from the exception and place it in request scope, so I can access it via EL in the page. I do this on line 37.

On lines 45 and 46, I leverage the JSF implicit navigation system and cause the server to navigate to the "viewExpired" page. This assumes, of course, that there is aviewExpired.xhtml page out there. 2015-08-19: This also assumes that the exception we are handling is not happening during the Render Response phase. If the exception is during the Render Response phase, it is not possible to use the NavigationHandler and you need to find another approach to convey the desired information. Naturally, you could parameterize this howevere you like, context-param, annotation, whatever. Line 46 causes the intervening lifecycle phases to be skipped.

Note that we have a try-finally block here, and in the finally block, on line 49, we call remove() on the iterator. This is an important part of the ExceptionHandlerusage contract. If you handle an exception, you have to remove it from the list of unhandled exceptions. That way, we know it's safe to call getWrapped().handle() on line 55.

Finally, let's see my cheesy viewExpired.xhtml page in action, shown at left.

The customized ViewExpiredException error page 

This page is not much more visually appealing than the default one, but that's not JSF's fault! The one in the JSF2 book will look nicer. Here's the source for this cheesy one.

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  4.      xmlns:f="http://java.sun.com/jsf/core">
  5. <h:head>
  6.   <title>Nice View Expired Page</title>
  7. </h:head>
  8. <h:body>
  9. <h:form>
  10.  
  11.     <p>To protect your security, we have taken the liberty of logging you
  12.     out. Those who sacrifice liberty for security deserve to have
  13.     their views expired.</p>
  14.  
  15.     <p>You were on page #{currentViewId}.  Maybe that's useful.</p>
  16.  
  17.   </h:form>
  18. </h:body>
  19. </html>
  20.    
  21.  

Note that we show the data from the exception on line 15.

This entry showed you how to programmatically intercept theViewExpiredException and do something nice with it. If you have any other state that you can show in the page, it's easy to include it in the Facelets view.

Technorati Tags: edburns

17 Comments

  • seltzerl Newbie

    seltzerl Sep 17, 2009 3:56 AM

    Ed, PLEASE don't let the book get released without a good index -- the first edition was great, but the index made it about 1/10 as useful as it would have been with a really good index. Thanks. Larry //
    • johnsoft Newbie

      johnsoft Apr 1, 2010 11:33 AM

      this not work with jboss richfaces in glassfish WARNING: ApplicationDispatcher[/uniplat] PWC1231: Servlet.service() for servlet Faces Servlet threw exception java.lang.NullPointerException      at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)      at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)      at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)      at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)      at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:822)      at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)      at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:519)      at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:488)      at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:379)      at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:485)      at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:679)      at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:311)      at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:241)      at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:334)      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)      at com.sun.grizzly.ContextTask.run(ContextTask.java:69)      at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)      at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)      at java.lang.Thread.run(Thread.java:619) //
      • nickarls-1034196 Newbie

        nickarls-1034196 Jul 29, 2010 2:50 PM

        Hi,   What is the recommended way of handling wrapped exceptions in JSF 2? I tried throwing an intentional NPE from an EJB and it ended up wrapped in EvaluationException/EJBTransactionRolledbackException/etc. Tried using the getRootCause() but even that didn't get me the NPE I threw. -Nik //
        • jiai Newbie

          jiai Jan 16, 2011 12:24 AM

          I've played around a bit with the version that is deployed with Mojarra 2.0.4. Unfortunately it doesn't seem to work properly when you are changing locales programmatically. The handler is triggered on:

          FacesContext.getCurrentInstance().getViewRoot().setLocale(currentLocale);

          A sample could be found at www.coreservlets.com/JSF-Tutorial/jsf2/#Events

          //
          • matsa Newbie

            matsa Apr 7, 2011 3:53 PM

            Hi!
            I'm attempting to adapt this example in my application but encounter this error in the call: nav.handleNavigation(fc, null, "viewExpired");

            java.lang.NullPointerException
            at org.apache.myfaces.application.NavigationHandlerImpl.getNavigationCase(NavigationHandlerImpl.java:203)
            at org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:77)

            Line 203:  String viewId = facesContext.getViewRoot().getViewId();

            getViewRoot() returns null for some reason. Any ideas as to how I can fix this problem?

            Appreciate any help. :)

            UPDATE: Of course I found a workaround as soon as I posted the question. I perform the following before calling the navigate-method. if ( fc.getViewRoot() == null ) {      UIViewRoot view = fc.getApplication().getViewHandler().createView( fc, vee.getViewId() );      fc.setViewRoot( view ); } Perhaps you can explain what happened to the view root. ;)

            //
            • supertonsky Newbie

              supertonsky May 27, 2011 9:48 AM

              Nice article Ed.

              However, I find this part of the JSF API ugly. No offense to its designers but how would anyone know that you're going to need a constructor that accepts ExceptionHandlerFactory instance as an argument? They could have made an abstract method to set that instance variable. No one knows until somebody like you posts something like this or read the source code.

              Hope to hear from you soon.

              //
              • cvarga Newbie

                cvarga Jun 10, 2011 11:16 PM

                Hi Ed

                Im having an unexpected problem with the ExceptionHandlerWrapper.

                Before the ExceptionHandlerWrapper handle the exception, the error is printed on the console. I do not want the exception apears inside the console. Something is intercepting and loggin it before entering the ExceptionHandlerWrapper

                I cannot find anyreference on this "issue".

                Any ideas ?

                Excluding this "problem", the ExceptionHandlerWrapper works perfectly.

                Thanks

                //
                • emrahkocaman Newbie

                  emrahkocaman Mar 26, 2012 10:25 PM

                  getUnhandledExceptionQueuedEvents return an empty collection in case of ajax requests. How should I proceed?

                  //
                  • Kimutua Newbie

                    Kimutua Oct 31, 2013 9:25 AM

                    I have successfully and Gracefully   dealt with  ViewExpiredException in JSF2. Good solution. //
                    • 2924048 Newbie

                      2924048 Aug 16, 2016 11:10 AM

                      Just applied your code into my new HR application. Works like a charme!

                      Thanks.

                       

                      Bruno