I am maintaining a tool formerly developed by an Indian for PDM system which use the dsl format file as input to generate one text file and one excel file.The text/excel file path stored in the session and appear on the result page for downloading , the tool always shows empty page when session is time out(the path is lost in the session), end users always complain about it and donot know what happened.I take charge of this tool and add one java filter to direct to session time-out page when the session is time out.
It's easy to implement it,you can create one backing bean and use the command link action attribute to invoke the file download.you can refer to the site:http://wiki.apache.org/myfaces/Sending_Files.In this way,you can only popup a excel download window.
 <h:commandLink action="#{downloadFileBean.downloadFile}">
<h:outputText value="#{apnStocklist.excelfile}"></h:outputText>
</h:commandLink>
But this tool is a little bit different and that's why I wrote this passage I donot know why the Indian implement it this way.This web application executes the logic and generate two Myfaces h:command links (text link and excel link) on one result page and then use java servlet to download the files(open in new window). The following is the link appearing on the result page(Myfaces jsp code)
<h:commandLink onclick="openWin('/servlet/DownloadFileServlet');">
<h:outputText value="#{apnStocklist.txtfile}"></h:outputText>
</h:commandLink>
I add one sessionExpired(sessionExpired.jsp) page and if the session time out , the result page and the newly servlet opening window both will direct to session expired page.
public void doFilter(ServletRequest servletRequest,
ServletResponse servletResponse, FilterChain filterChain)
  throws IOException, ServletException  {
 HttpServletRequest request = (HttpServletRequest) servletRequest;
HttpServletResponse response = (HttpServletResponse) servletResponse;
boolean sessionInvalid = (null != request.getRequestedSessionId())
&& !request.isRequestedSessionIdValid();
HttpSession session = request.getSession();
System.out.println("-----------------------------" + request.getRequestURI() + "----------------------------");
System.out.println("session is new:---" + session.isNew());
System.out.println("request session id:---" + request.getRequestedSessionId() + " session id:---" + session.getId());
  if (sessionInvalid) {
response.sendRedirect(request.getContextPath() + "/jsp/"
+ SESSION_TIME_OUT_PAGE);
return;
 }
filterChain.doFilter(servletRequest, servletResponse);
 } I check the most of the web sites, including the spring security, they always use the following code to check whether session is time out or not.
boolean sessionInvalid = (null != request.getRequestedSessionId())&& !request.isRequestedSessionIdValid(); But for this tool, since the downloading is opened via new window(Multiple requests), It behaves differently for IE6 and firedox. As the Myfaces ManagedBean is in request scope,clicking the link will call the servlet code as well as ManagedBean constructor code(initialize the bean instance) .For Firefox,It 's working fine, both the window direct to session time out page ,But for the IE6 ,only the servlet window directs, the result page doesnot. After debuging the application, I found the application call order is not the same,I donot know why?when the session time outIE6: the servlet code will call first, and then direct to session expired page, then the result page (ManagedBean code) called.Firefox : the servlet code will call first,the result page,session expired page,session expired page(both direct to)
IE6: 8F1F773477460348836FB47C440FBD6E is the session Id before session time out and when the session time out, the servlet will create one session and then request.getRequestSessionId changed
-----------------------------DownloadFileServlet----------------------------
session is new:---true
request session id:---8F1F773477460348836FB47C440FBD6E session id:---DC720FACE7367E81680542290EF6AE9A
----------------------------sessionExpired.faces----------------------------
session is new:---false
request session id:---DC720FACE7367E81680542290EF6AE9A session id:---DC720FACE7367E81680542290EF6AE9A
-----------------------------results.faces----------------------------
session is new:---false
request session id:---DC720FACE7367E81680542290EF6AE9A session id:---DC720FACE7367E81680542290EF6AE9A
Firefox
-----------------------------DownloadFileServlet----------------------------
session is new:---true
request session id:---2EEFE6AF9DE431CDB555D86A7C4C77CE session id:---CC5A8338993E0A4F2CA9B2AB7CECFA56
-----------------------------results.faces----------------------------
session is new:---true
request session id:---2EEFE6AF9DE431CDB555D86A7C4C77CE session id:---E08C640D9EE6815CCBEA8A4A1F06573B
-----------------------------sessionExpired.faces----------------------------
session is new:---false
request session id:---CC5A8338993E0A4F2CA9B2AB7CECFA56 session id:---CC5A8338993E0A4F2CA9B2AB7CECFA56
-----------------------------sessionExpired.faces----------------------------
session is new:---false
request session id:---E08C640D9EE6815CCBEA8A4A1F06573B session id:---E08C640D9EE6815CCBEA8A4A1F06573B
Finally I have two ways to solve it.
1.donot use pure servlet to download files ,just use managed bean to download files instead(without popup window)
2.use session.getAttribute("User") == null to check whether the session is time out or not.
Meanwhile, we often encounter the following exceptions about session.That's because before we call the session.setAttribute("User"), the session is already invalid.when encountering this exception, we have to find what has caused the application session invalid before we use session to set attributes.
Caused by: java.lang.IllegalStateException: setAttribute: Session already invalidated
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1289)
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1254)
at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:130)
Ref:
http://techieexchange.wordpress.com/2008/02/21/jsf-session-expired-timeout-solution/
|