Re: Problem Using Orchestra with Realm after Session-Timeout
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
Re: Problem Using Orchestra with Realm after Session-Timeout
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
RE: Problem Using Orchestra with Realm after Session-Timeout
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.
Ciao,
Mario
Re: Problem Using Orchestra with Realm after Session-Timeout
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)
Re: Problem Using Orchestra with Realm after Session-Timeout
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)
Re: Problem Using Orchestra with Realm after Session-Timeout
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) -- _ Filip Lyncker, Dipl.-Inform. (FH) Lyncker Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/89038960 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 4023897051 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis -- _ Filip Lyncker, Dipl.-Inform. (FH) Lyncker Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/89038960 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 4023897051 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis
Re: Problem Using Orchestra with Realm after Session-Timeout
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
Re: Problem Using Orchestra with Realm after Session-Timeout
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
Re: Problem Using Orchestra with Realm after Session-Timeout
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
RE: Problem Using Orchestra with Realm after Session-Timeout
Hi! 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. Unhappily JSF 1.2 will throw an ViewExpiredException or so very annoying! Well, not too annoying, but you should take care of that in some way to prevent propagating this to the user ... what we do ATM btw :-) 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... https://javaserverfaces.dev.java.net/download.html Ciao, Mario
Re: Problem Using Orchestra with Realm after Session-Timeout
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.OrchestraFacesContextFactory $...@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) -- _ Filip Lyncker, Dipl.-Inform. (FH) Lyncker Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/89038960 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 4023897051 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis
