Hi,

The solution I use is to put a "ping" script in the page which sends a
request to the server every couple of minutes. With that, the session
never times out while the browser window is open, and so the problem
never occurs.

Of course this requires javascript, but is javascript is disabled then
so are all AJAX operations so then your filter will handle everything ok.

I don't know of any solution to properly handle session-timeout for ajax
requests. However I don't use ajax much. Maybe one of the ajax experts
here can comment on that...

Regards,
Simon

Ravizzz schrieb:
> Simon,
> 
> You are right, Except the links to other jsp/html pages all other components
> like table and tabs give us this problem. Do you know any sort of solution
> for this?
> 
> 
> Simon Kitching wrote:
>> My guess is that your timeout-handling approach is failing to work with
>> any AJAX or frame-based pages, and that these tabs are just one case
>> where ajax or frames are being used.
>>
>> The problem is that when a browser is refreshing a whole page, a filter
>> can return an http-redirect command and the browser will then replace
>> the current page with the redirected-to url.
>>
>> When the browser is just fetching a frame, only the frame contents will
>> get directed, not the whole frameset.
>>
>> And when a browser is using XmlHttpRequest to do an AJAX operation,
>> there is no obvious way for a filter to tell the browser to give up and
>> redirect the current window to a new url. At least not one I know of (I
>> presume sending back an http-redirect doesn't work..)
>>
>> Regards,
>> Simon
>>
>> Ravizzz schrieb:
>>> We have implemented similar way of session timeout in our application
>>> using
>>> filter in web.xml.
>>>
>>> But we are facing one problem with this way of timeout.
>>>
>>> Once Session expires proper logout doesn’t not happen while clicking on
>>> tabs
>>> created in jspx using \<tr:panelTabbed\> tags
>>>
>>>
>>> This is very specifically for the tabs and everything works fine while
>>> clicking on link or buttons etc
>>>
>>> In server logs we get Session Timed Out message, however at UI nothing
>>> happens, same teb is displayed and never logs out.
>>>
>>> Additionally we get the below message in logs:-
>>>
>>> [3/4/09 16:19:01:125 IST] 00000035 StateManagerI E
>>> org.apache.myfaces.trinidadinternal.application.StateManagerImpl
>>> restoreView
>>> Could not find saved view state for token -1909e0a
>>>
>>> Any help or pointers would be appreciated.
>>>
>>>
>>> chrishane wrote:
>>>> I have a generic search screen (standard input form) that displays the 
>>>> results on the "next" page using a <tr:table>.
>>>>
>>>> If the user hits the refresh button any time prior to the HTTPSession 
>>>> timeout, then the form is resubmitted and the search generated again
>>>> (could 
>>>> display different results if the underlying data has been updated -
>>>> which 
>>>> is what we want to happen).
>>>>
>>>> If the user leaves (for a time greater than the HTTPSession timeout) the 
>>>> results screen, comes back and hits the refresh button after the
>>>> timeout, 
>>>> the "Find" screen is displayed again.
>>>>
>>>> I am using Trinidad 1.0 Myfaces 1.1, Jboss 4.0.x, Seam 1.2p1 with client 
>>>> side state saving.
>>>>
>>>> One of the first errors in the log is:
>>>>
>>>> 2007-06-29 15:35:17,593 ERROR [STDERR] Jun 29, 2007 3:35:17 PM 
>>>> org.apache.myfaces.trinidadinternal.application.StateManagerImpl 
>>>> restoreView SEVERE: Could not find saved view state for token 7cad43c0
>>>>
>>>> Which is why I'm assuming it is the HTTPSession timeout.
>>>>
>>>> Is there anything I can do so that the "refresh" will re-run the search
>>>> and 
>>>> not show the Find screen?
>>>>
>>>> Thanks,
>>>> Chris....
>>>>
>>>>
>>>>
>>
>> -- 
>> -- Emails in "mixed" posting style will be ignored
>> -- (http://en.wikipedia.org/wiki/Posting_style)
>>
>>
> 

Reply via email to