Mario Ivankovits schrieb: > Hi! >> -----Original Message----- >> From: Filip Lyncker [mailto:lync...@lyth.de] >> Sent: Thursday, February 12, 2009 11:29 AM > > Yep, here it is: >> javax.faces.application.ViewExpiredException: >> viewId:/pages/start/actuell.jsf - View /pages/start/actuell.jsf could >> not be restored. > > >> if (is11CompatEnabled(facesContext)) { // the faces > > What you can do ist to figure out how to enable the JSF 1.1 compat mode, > which then will simply rerender the page. > Or you try/catch the ViewExpired exception in an filter (probably) and > forward to your login/menu/whatever page. > > The first suggestion might restore the page in an invalid state as all the > beans are gone, so I'd opt for the second suggestion (try/catch). > Unhappily I've never done this myself (... I should have ...). I'd start with > a servlet filter .. or a PhaseListener. > > Anyone else with a better solution? > > Yes, a third one: If you are using richfaces you can use the a4j:poll > component on each page which polls the server, lets say, once every minute. > This will prevent the session from timeout as long as the browser points to > your application. This also allows you to configure a very short session > timeout (5 minutes) as nothing bad happens as long as the browser is open. > This is very much like a RichClient behaviour. > BTW: This is the solution we use in our application.
Mario is quite right: in JSF1.2 the behaviour has changed when the view cannot be restored (eg due to session timeout). The old behaviour was to just render the requested page, while the new behaviour is to throw ViewExpiredException. I hadn't even realized this - thanks for the info Mario! So whatever bug you were getting before is now gone - getting a ViewExpiredException is the correct and expected behaviour in this case. As Mario noted, the new behaviour is actually better. For many pages, attempting to just render them won't work properly as the application state isn't correctly set up. For example, in a "master-detail" type scenario, if the user is on the "detail" page when the session expires, then trying to re-render it with all-new backing beans is probably just going to crash or cause some other kind of weird behaviour. You can use the <error-page> element in the web.xml to specify a page to redirect to when an exception is thrown. However if I remember correctly, all kinds of JSF exceptions get wrapped in one generic type so it is not possible to redirect to a page specifically for ViewExpiredException handling using this mechanism. I could be wrong here though.. So if you need more customized behaviour in this case, you will probably need to configure your web.xml to specify a filter (I don't think a PhaseListener will work). In the exceptionhandler/filter you should be able to explicitly do the old JSF1.1 behaviour if you really want, just by extracting the original URL from the request then forwarding to that URL (but using GET, so no attempt to restore the view is done). Better would probably just be to forward to a page that says "sorry your session timed out; click here to go to the webapp home page". Or as Mario pointed out, use ajax components or some explicit javascript to "poll" the server, thus ensuring that http session timeouts never occur while the browser window is open. This approach works really nicely, as long as you have some common header or footer that every page includes, so that the "poll" logic only needs to be implemented in one place. Regards, Simon -- -- Emails in "mixed" posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
