Hi Simon ,
thanks a lot for that infos ! I installed the newest Versions of
Orchestra 1.3 and jsf RI (1.2_12) now and the behave is different now :
no more null pointer , but still an exception ...
after the session timeout i get the following log output :
12.02.2009 11:09:35 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...@19ae920]
12.02.2009 11:11:16 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:76)
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)
as you suggested, I installed the sources to see what exactly happens:
in the function excetue , it calls the dophase function wich throws the
exception :
if (viewRoot == null) {
if (is11CompatEnabled(facesContext)) { // the faces
context is our orchestra faces context.
// 1.1 -> create a new view and flag that the
response should
// be immediately rendered
viewRoot = viewHandler.createView(facesContext, viewId);
facesContext.renderResponse();
} else {
Object[] params = {viewId};
throw new ViewExpiredException(
/////////////////this exception is thrown ....
MessageUtils.getExceptionMessageString(
MessageUtils.RESTORE_VIEW_ERROR_MESSAGE_ID,
params),
viewId);
}
but how can we avoid that the framework trys to restore the context wich
is not any more valid ?
regards,
Filip
Simon Kitching schrieb:
Hi,
I presume you're using server-side state-saving.
So the browser accesses foo.jsf, and is returned a page containing a
special hidden field that is the "key" of the saved state within the
user's http session on the server.
Then the user's http session times out.
The user clicks a "submit" button which posts back to foo.jsf, passing
the hidden state "key" as one of the form values.
The webserver realizes that the user has no http session, and therefore
no "login". It therefore saves the current posted params, and redirects
to a login page. When the user fills in username/password and submits,
the server authenticates then "continues" with the original saved
submit. As you see in your filter, the http-session is a new one. All
the above is normal servlet container behaviour.
The JSF implementation will then see a request to restore state from the
session, with a specific key. But the session is empty, so the specified
view state cannot be ignored.
What normally happens then is that the JSF implementation will just log
an "unable to restore view" message to its logfile, and simply *render*
the specified page rather than doing a "postback", just as if the user
had done a GET request for the url rather than a POST request.
Quite why you are getting an exception at this point rather than just
seeing the specified page rendered is unknown. There is probably some
library or class in your app that is assuming that on POST there is a
restored view - though in this special "failed to find view" case there
is not.
The question is *what* code is causing this problem. The easiest way is
probably to download the source jarfile for your mojarra (Sun RI)
version and put a breakpoint on the
com.sun.faces.lifecycle.RestoreViewPhase.execute
method. Then just try it, and step through the mojarra code until you
see what the problem is.
Getting the "source jarfile" for MyFaces JSF is easy; we publish it in
the Maven repository along with the binary jarfiles. I don't know where
to find the source for Mojarra releases...
Regards,
Simon
