Details
Description
<error-page>
<exception-type>com.icesoft.faces.webapp.http.core.SessionExpiredException</exception-type>
<location>/index.jsp</location>
</error-page>
I have tried this using sync and async, and tested on 1.7.1 build 2, 1.7.0, and 1.6.2.
-
Hide
- redirectonexpiry.zip
- 5.18 MB
- Mircea Toma
-
- redirectonexpiry/.DS_Store 6 kB
- __MACOSX/redirectonexpiry/._.DS_Store 0.1 kB
- redirectonexpiry/build.xml 2 kB
- redirectonexpiry/src/.DS_Store 6 kB
- __MACOSX/redirectonexpiry/.../._.DS_Store 0.1 kB
- redirectonexpiry/src/com/.DS_Store 6 kB
- __MACOSX/redirectonexpiry/.../._.DS_Store 0.1 kB
- redirectonexpiry/src/.../icesoft/.DS_Store 6 kB
- __MACOSX/redirectonexpiry/.../._.DS_Store 0.1 kB
- redirectonexpiry/.../SessionBoundBean.java 3 kB
- redirectonexpiry/src/.../ViewBoundBean.java 0.6 kB
- redirectonexpiry/web/.DS_Store 6 kB
- __MACOSX/redirectonexpiry/.../._.DS_Store 0.1 kB
- redirectonexpiry/web/index.jsp 0.1 kB
- redirectonexpiry/web/page.jspx 0.5 kB
- __MACOSX/redirectonexpiry/.../._page.jspx 0.1 kB
- redirectonexpiry/web/WEB-INF/.DS_Store 6 kB
- __MACOSX/redirectonexpiry/.../._.DS_Store 0.1 kB
- redirectonexpiry/.../SessionBoundBean.class 2 kB
- redirectonexpiry/.../SessionBoundBean.java 3 kB
- redirectonexpiry/web/.../ViewBoundBean.class 1 kB
- redirectonexpiry/web/.../ViewBoundBean.java 0.6 kB
- redirectonexpiry/web/.../faces-config.xml 3 kB
- redirectonexpiry/.../backport-util-concurrent.jar 319 kB
- redirectonexpiry/.../commons-beanutils.jar 184 kB
- redirectonexpiry/.../commons-collections.jar 558 kB
- redirectonexpiry/.../commons-digester.jar 140 kB
- redirectonexpiry/.../commons-discovery.jar 70 kB
- redirectonexpiry/web/.../lib/commons-el.jar 110 kB
- redirectonexpiry/.../commons-fileupload.jar 87 kB
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Currently, SessionExpiredExceptions are used to pass control back up the calling chain to the MainSessionBoundServlet when an IllegalStateException is thrown at some point in the framework. This exception is then used to generate the <session-expired> response for the browser, which is handled by the command handler in the bridge to dispose views and clean itself up.
This potentially could be done by defining a context param (It can't be the <error-code> element because those aren't exposed to the servlet) that was to be included with the <session-expiry> command in order for the bridge to dispose of the views, and perhaps navigate to the session expiry page? Then we have to hope that it's a .jsp that doesn't have any icefaces components so an endless session loop is avoided.
This syntax for redirecting on session expired exception can't be readily supported, as explained above:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.html</location>
</error-page>
We should create some tutorials that illustrates supported mechanisms for navigating to a specific page upon session expiry (sync. and async).
Invoke DisposableBean.dispose() methods before anything else when shutting down the session bound server.
I am attaching a sample webapp that achieves the redirect on session expiry functionality.
Add redirection on session expiry functionality for application developer's convenience. The way it would be configured should be similar to redirection on connection lost feature.
Redirect on session expiry. Now the redirect works also in synchronous mode.
'com.icesoft.faces.sessionExpiredRedirectURI' context parameter introduced to specify the redirection URI on session expiry.
Tested successfully with 1.7 branch.
Investigate and verify
I have an application that this works in. It successfully navigates to my configured page on session timeout. My test application has the following:
<context-param>
<param-name>com.icesoft.faces.sessionExpiredRedirectURI</param-name>
<param-value>'sessionExpired.jsp'</param-value>
</context-param>
and I do have the connection status indicator on the page.
I am working with icefaces 1.7.2 SP1.
<context-param>
<param-name>com.icesoft.faces.synchronousUpdate</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.icesoft.faces.sessionExpiredRedirectURI</param-name>
<param-value>sessionExpired.jsp</param-value>
</context-param>
This does NOT work in synchronous mode. It only works on asynchronous mode.
Greg notes:
That wont work. The way the error code stuff works is that if the request throws an exception, the servlet container fetches the appropriate file and serves up the response including the contents of the file.
This bit in web.xml
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.html</location>
</error-page>
causes this type of response to be sent to the browser:
HTTP/1.1 500 java.lang.RuntimeException
Server: Apache-Coyote/1.1
ETag: W/"278-1209424220000"
Last-Modified: Mon, 28 Apr 2008 23:10:20 GMT
Content-Type: text/html
Content-Length: 278
Date: Thu, 05 Jun 2008 15:23:45 GMT
Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Insert title here</title>
</head>
<body>
Something bad happened.
</body>
</html>[52.659103s]
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Thu, 05 Jun 2008 15:23:45 GMT
For this to work, the exception has to be thrown to the servlet container, and the servlet container fetches the resource and serves it up all in one motion.
The framework doesn't throw sessionExpired exceptions. The framework and bridge engage in a protocol to shut down the bridge instance and dipose of the views.