FYI, there is a whole section about error handling (and a link to an
example that handles the ViewExpiredException) in the Wiki.
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Feb 12, 2009, at 5:43 AM, Simon Kitching <skitch...@apache.org>
wrote:
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)