You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Vinaya Tirikkovalluru <vi...@converge.com> on 2008/12/17 22:08:36 UTC

javax.faces.application.ViewExpiredException:

Hi,

 

We have upgraded from Tomahawk 1.1.6 to Tomahawk 1.1.8

After this, we have been getting a lot of
javax.faces.application.ViewExpiredExceptions

I was under the impression that
javax.faces.application.ViewExpiredException is caused only when the
session expires.

Anybody else had this problem earlier?

Could any one please tell me what are the other scenarios where this is
caused?

 

Thanks

Vinaya

 

 

 



This electronic message is intended only for the use of the individual(s) or entity(ies) named above and may contain information which is privileged and/or confidential.  If you are not the intended recipient, be aware that any disclosure, copying, distribution, dissemination or use of the contents of this message is prohibited.  If you received this message in error, please notify the sender immediately.

Re: javax.faces.application.ViewExpiredException:

Posted by Ali Ok <al...@aliok.info>.
Another scenerio:
In our projects, bad configured clustering caused ViewExpiredException.
It is not easy to find out the reason for this problem.

Regards,
Ali

2008/12/18 Simon Kitching <sk...@apache.org>

> Vinaya Tirikkovalluru schrieb:
> >
> > Hi,
> >
> >
> >
> > We have upgraded from Tomahawk 1.1.6 to Tomahawk 1.1.8
> >
> > After this, we have been getting a lot of
> > javax.faces.application.ViewExpiredExceptions
> >
> > I was under the impression that
> > javax.faces.application.ViewExpiredException is caused only when the
> > session expires.
> >
> > Anybody else had this problem earlier?
> >
> > Could any one please tell me what are the other scenarios where this
> > is caused?
> >
> Firstly, note that this applies only when "server-side-state-saving" is
> enabled. A ViewExpiredException will never occur with
> "client-side-state-saving".
>
> Myfaces keeps a cache of previous views in the session. At the start of
> each render phase, a new "view key" is allocated, and written into a
> hidden field in the html form. At the end of the render phase, the
> current view is stored into the cache using that key.
>
> On postback, if the "view key" specified by the posted form data does
> not match any entry in the cache, then a ViewExpiredException is reported.
>
> The cache has a fixed size, so that a user session does not grow
> continuously; when a view is stored into a full cache, the oldest entry
> is discarded. This allows a fixed-size number of "back button" clicks to
> work (the submitted form will contain an old "view key"). The actual
> number is configurable.
>
> Unfortunately this approach does not work too well if an application has
> multiple windows open; there is still just one cache, so if one window
> is used repeatedly then it will eventually push the saved view for other
> open windows out of the cache; then submitting the other window will
> cause a ViewExpiredException. Unfotunately http provides no way to know
> which window is which, so it is not possible to have a per-window cache.
>
> But all this view-cache-management is done by the jsf core
> implementation, *not* tomahawk. So I cannot think why upgrading Tomahawk
> is causing problems for you. Hopefully the above info will help you
> figure out what the actual problem is..
>
> Regards,
> Simon
>
> --
> -- Emails in "mixed" posting style will be ignored
> -- (http://en.wikipedia.org/wiki/Posting_style)
>
>

RE: javax.faces.application.ViewExpiredException:

Posted by Vinaya Tirikkovalluru <vi...@converge.com>.
Hi Simon,

Thanks for the details.
I have a sessiontimeout filter which checks if the session has timedout
for each request and will delegate to the next servlet if the session is
valid and redirects the user to the login page if the session in invalid
(timed out)

The code is


package com.converge.framework.logging;

import java.util.Date;

import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

import org.acegisecurity.context.HttpSessionContextIntegrationFilter;
import org.acegisecurity.context.SecurityContext;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;


public class SessionListener implements HttpSessionListener {
	protected final Log logger = LogFactory.getLog(this.getClass());
	public SessionListener() {
		
	}
	public void sessionCreated(HttpSessionEvent event) {
		System.out.println("Current Session created : " +
event.getSession().getId() + " at "+ new Date());
		logger.info("Current Session created : " +
event.getSession().getId() + " at "+ new Date());
	}
	public void sessionDestroyed(HttpSessionEvent event) {
	// get the destroying session...
	HttpSession session = event.getSession();
	System.out.println("Current Session destroyed :" +
session.getId() + " Logging out user...");
	logger.info("Current Session destroyed :" + session.getId() + "
Logging out user...");
	

	/*

	* nobody can reach user data after this point because session is
invalidated already.
	* So, get the user data from session and save its logout
information 
	* before losing it.
	* User's redirection to the timeout page will be handled by the
SessionTimeoutFilter.
	*/










	// Only if needed

	try {

	prepareLogoutInfoAndLogoutActiveUser(session);
	} catch(Exception e) {

	logger.info("Error while logging out at session destroyed : " +
e.getMessage());

	}
	}
	/**








	* Clean your logout operations. 
	*/

	public void prepareLogoutInfoAndLogoutActiveUser(HttpSession
httpSession) {

		SecurityContext context = (SecurityContext) httpSession
	
.getAttribute(HttpSessionContextIntegrationFilter.ACEGI_SECURITY_CONTEXT
_KEY);
	  if (context != null) {
	   httpSession.invalidate();
	  }


	}
	
	
	} 



Any ideas if this is causing any issues?

Thanks
Vinaya


-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org] 
Sent: Thursday, December 18, 2008 3:38 AM
To: MyFaces Discussion
Subject: Re: javax.faces.application.ViewExpiredException:

Vinaya Tirikkovalluru schrieb:
>
> Hi,
>
>  
>
> We have upgraded from Tomahawk 1.1.6 to Tomahawk 1.1.8
>
> After this, we have been getting a lot of
> javax.faces.application.ViewExpiredExceptions
>
> I was under the impression that
> javax.faces.application.ViewExpiredException is caused only when the
> session expires.
>
> Anybody else had this problem earlier?
>
> Could any one please tell me what are the other scenarios where this
> is caused?
>
Firstly, note that this applies only when "server-side-state-saving" is
enabled. A ViewExpiredException will never occur with
"client-side-state-saving".

Myfaces keeps a cache of previous views in the session. At the start of
each render phase, a new "view key" is allocated, and written into a
hidden field in the html form. At the end of the render phase, the
current view is stored into the cache using that key.

On postback, if the "view key" specified by the posted form data does
not match any entry in the cache, then a ViewExpiredException is
reported.

The cache has a fixed size, so that a user session does not grow
continuously; when a view is stored into a full cache, the oldest entry
is discarded. This allows a fixed-size number of "back button" clicks to
work (the submitted form will contain an old "view key"). The actual
number is configurable.

Unfortunately this approach does not work too well if an application has
multiple windows open; there is still just one cache, so if one window
is used repeatedly then it will eventually push the saved view for other
open windows out of the cache; then submitting the other window will
cause a ViewExpiredException. Unfotunately http provides no way to know
which window is which, so it is not possible to have a per-window cache.

But all this view-cache-management is done by the jsf core
implementation, *not* tomahawk. So I cannot think why upgrading Tomahawk
is causing problems for you. Hopefully the above info will help you
figure out what the actual problem is..

Regards,
Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)



This electronic message is intended only for the use of the individual(s) or entity(ies) named above and may contain information which is privileged and/or confidential.  If you are not the intended recipient, be aware that any disclosure, copying, distribution, dissemination or use of the contents of this message is prohibited.  If you received this message in error, please notify the sender immediately.

Re: javax.faces.application.ViewExpiredException:

Posted by Simon Kitching <sk...@apache.org>.
Vinaya Tirikkovalluru schrieb:
>
> Hi,
>
>  
>
> We have upgraded from Tomahawk 1.1.6 to Tomahawk 1.1.8
>
> After this, we have been getting a lot of
> javax.faces.application.ViewExpiredExceptions
>
> I was under the impression that
> javax.faces.application.ViewExpiredException is caused only when the
> session expires.
>
> Anybody else had this problem earlier?
>
> Could any one please tell me what are the other scenarios where this
> is caused?
>
Firstly, note that this applies only when "server-side-state-saving" is
enabled. A ViewExpiredException will never occur with
"client-side-state-saving".

Myfaces keeps a cache of previous views in the session. At the start of
each render phase, a new "view key" is allocated, and written into a
hidden field in the html form. At the end of the render phase, the
current view is stored into the cache using that key.

On postback, if the "view key" specified by the posted form data does
not match any entry in the cache, then a ViewExpiredException is reported.

The cache has a fixed size, so that a user session does not grow
continuously; when a view is stored into a full cache, the oldest entry
is discarded. This allows a fixed-size number of "back button" clicks to
work (the submitted form will contain an old "view key"). The actual
number is configurable.

Unfortunately this approach does not work too well if an application has
multiple windows open; there is still just one cache, so if one window
is used repeatedly then it will eventually push the saved view for other
open windows out of the cache; then submitting the other window will
cause a ViewExpiredException. Unfotunately http provides no way to know
which window is which, so it is not possible to have a per-window cache.

But all this view-cache-management is done by the jsf core
implementation, *not* tomahawk. So I cannot think why upgrading Tomahawk
is causing problems for you. Hopefully the above info will help you
figure out what the actual problem is..

Regards,
Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)