Dear everyone,
I found a solution wich is not final but ok for now...
as described if you follow the link Kito sent i'm doing a hack now to
avoid the crash:
http://www.jsfcentral.com/listings/A20158?link
To verify that someone is coming from outside ( the login page ) we send
a URL parameter as described in a comment in the jsfcentral discussion.
( the comment from by *Josep Mena).
*Well , with this trick , everything works fine, but a a exception wich
is still thrown , but handled. Maybe someone from you guys have an idea
for that little last problem ;)
anyway , thanks a lot for your thoughts...
Regards,
Filip
here the exception :
16.02.2009 17:01:42 com.sun.faces.lifecycle.Phase doPhase
SCHWERWIEGEND: JSF1054: (Phase ID: RESTORE_VIEW 1, View ID: ) Exception
thrown during phase execution:
javax.faces.event.phaseevent[source=com.sun.faces.lifecycle.lifecyclei...@1c85f78]
16.02.2009 17:01:42 org.apache.catalina.core.StandardWrapperValve invoke
SCHWERWIEGEND: Servlet.service() for servlet Faces Servlet threw exception
javax.faces.application.ViewExpiredException:
viewId:/pages/start/actuell.jsf - View /pages/start/actuell.jsf could
not be restored.
at
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:185)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
at
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.orchestra.filter.OrchestraServletFilter.doFilter(OrchestraServletFilter.java:77)
at
org.apache.myfaces.orchestra.lib.CompoundFilter$1.doFilter(CompoundFilter.java:58)
at
org.apache.myfaces.orchestra.lib._NullFilter.doFilter(_NullFilter.java:45)
at
org.apache.myfaces.orchestra.lib.CompoundFilter.doFilter(CompoundFilter.java:63)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
de.we.myproject.util.SessionTimeoutFilter.doFilter(SessionTimeoutFilter.java:93)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
*
*
Kito Mann schrieb:
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:lyncker@
.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)
--
_________________________________
Filip Lyncker, Dipl.-Inform. (FH)
Lyncker & Theis GmbH
Wilhelmstr. 16
65185 Wiesbaden
Germany
Fon +49 611/9006951
Fax +49 611/9406125
Handelsregister: HRB 23156 Amtsgericht Wiesbaden
Steuernummer: 4023897051
USt-IdNr.: DE255806399
Geschäftsführer:
Filip Lyncker,
Armin Theis
