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 Filip Lyncker schrieb: > Dear Simon, > > you're right, im sorry, Im using the version 1.2.03 of RI JSF. Yes I > know there is a newer version also from orchestra. But first I tried to > understand the problem than just to upgrade the version of my frameworks > b/c I allways had a lot other problems than ... > let me describe it a bit more: > > i include the SessionTimeoutFilter because I hope to find something > there. If the session-timeout occurs, ill be redirected to the login > page. If I > relogin now, first I can stop in that filter. But the session is valid, > but its a new one. If i would know what to do here everything would be > fine: > > 1. I need to recognize that the user is coming from the loginpage ( and > not from another party of my app ) > 2. than I need to delete the restored stuff ( request URL or whatever) > that will be crash my app or frameworks in the next second. > > as described in the servlet spezfication : " If the user is authorized, > the client is redirected to the resource using the stored URL path. " > this seems to be the problem , im not sure what all is transported in > that url, or if there are more infos in it, but > I think that maybe the orchestra or something around it, doesnt like the > garbage from the "user before.." > > > thanks again for helping me... > > Regards, > > Filip > > > > > Simon Kitching schrieb: >> I don't think this is anything to do with Orchestra. >> >> This message: >> >> WARNUNG: executePhase(RESTORE_VIEW1, >> org.apache.myfaces.orchestra.lib.jsf. >> orchestrafacescontextfactor...@108e435) >> threw exception >> java.lang.NullPointerException >> at >> com.sun.faces.lifecycle.RestoreViewPhase.execute( >> RestoreViewPhase.java:163) >> >> says that Sun's class RestoreViewPhase.java:163 threw the exception, and >> that it happened to be called from an executePhase that had an >> OrchestraFacesContextFactory instance as a parameter. >> >> It doesn't mean that the OrchestraFacesContextFactory class had anything >> to do with the problem. It *might* be something related to orchestra, >> but you would have to look at that line in the Mojarra (Sun JSF RI) >> source code to tell what the actual problem is. >> >> And as Kito pointed out, you really MUST say what software versions you >> are using if you want help. Even after Kito pointed this out, you still >> have not said what version of Mojarra you are using... >> >> And by the way, Orchestra 1.3 is available... >> >> Regards, >> Simon >> >> Filip Lyncker schrieb: >> >>> Dear Kito, >>> >>> We are using JSF(RI) and Orchestra.core v1.2 ... so do you have some >>> ideas for me? >>> >>> >>> thanks & regards, >>> >>> >>> filip >>> >>> >>> >>> >>> Kito Mann schrieb: >>> >>>> Folio, >>>> >>>> Which version of the reference implementation are you using, and >>>> which version of Orchestra? >>>> >>>> Sent from my iPhone >>>> >>>> http://www.jsfcentral.com >>>> http://www.Virtua.com >>>> >>>> >>>> On Feb 10, 2009, at 2:02 PM, Filip Lyncker <lync...@lyth.de> wrote: >>>> >>>> >>>>> Dear Group , >>>>> >>>>> I have a problem in an enviroment with orchestra,jsf,spring and >>>>> authentikation using a tomcat realm. >>>>> >>>>> If the session timed out the user is redirected from the secured area >>>>> to the login page wich is in the free-area. But the realm seems to >>>>> store the last request. >>>>> After login in the app crashes with a null pointer like shown in the >>>>> following... >>>>> Maybe I need to configure orchestra or spring in any way to handle >>>>> that request? >>>>> >>>>> thanks a lot for help .. >>>>> >>>>> >>>>> cheers >>>>> >>>>> Filip >>>>> >>>>> >>>>> >>>>> [21:01:28] Nabil : 10.02.2009 20:27:52 >>>>> com.sun.faces.lifecycle.LifecycleImpl phase >>>>> WARNUNG: executePhase(RESTORE_VIEW >>>>> 1,org.apache.myfaces.orchestra.lib.jsf.orchestrafacescontextfactor...@108e435) >>>>> >>>>> threw exception >>>>> java.lang.NullPointerException >>>>> at >>>>> com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:163) >>>>> >>>>> >>>>> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248) >>>>> at >>>>> com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) >>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) >>>>> 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 >>>>> de.lyth.huntersBase.util.SessionTimeoutFilter.doFilter(SessionTimeoutFilter.java:56) >>>>> >>>>> >>>>> 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) >>>>> 10.02.2009 20:27:52 org.apache.catalina.core.StandardWrapperValve >>>>> invoke >>>>> SCHWERWIEGEND: Servlet.service() for servlet Faces Servlet threw >>>>> exception >>>>> java.lang.NullPointerException >>>>> at >>>>> com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:163) >>>>> >>>>> >>>>> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248) >>>>> at >>>>> com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) >>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) >>>>> >>>>> >> >> > > -- -- Emails in "mixed" posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
