myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajneesh K Rajput <>
Subject Re: ViewExpiredException: (Myfaces1.2.6 and Richfaces3.3.0) Possible problem and solution discussion.
Date Fri, 10 Jul 2009 06:18:52 GMT

Hi All,
I have noticed one more thing is that we have mapped the Faces Servlet in
web.xml with /faces/*, so typically it is treating every request is a normal
JSF request and causing images, CSS to be cached in the same map which could
be the actual cause of this problem in this latest release.

We should change the Faces Servlet mapping to either something /*.jsp. Lets
do this change and it must solve our problem permanently. 

Rajneesh K Rajput wrote:
> There are lots of details given for the rich faces but they are just to
> explain the problem that we are facing, but want to discuss something
> related to my faces latest implementation.
> <p> Actual Problem </p>
> We recently upgraded Rich Faces to 3.3.0 along with my faces 1.2.6. We
> were facing a problem that if we access the application first time, first
> page gets render properly but further it does not work. But we simply
> relogin into application again there after same set of pages work fine.
> <p> Discussion point in My faces  </p>
> Anyways, what I found is related to Rich Faces class how it is storing the
> view state map, but want to confirm here also why MyFaces new
> implementation for the class RestoreViewExecutor throws an exception if no
> view is found in post back request, while older version of this class was
> creating a new instance of view state if not found. 
> <p> ------------------------------------------------------ </p>
> Details for Rich Faces related work, not required here in my faces forum
> but will help to understand the problem that we are facing now. 
> <p></p>
> Please see what we found in this.
> <p></p>
> Initial configurations were as follows..
> javax.faces.STATE_SAVING_METHOD=server
> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 4
> <p></p>
> Always, if we use new browser / (Clean browser cache) and login into
> application first page is rendered properly. But, if we click any of the
> link on this page then ViewExpiredException is thrown because in the post
> back request required view id is not available in the server cached views
> list.
> <p></p>
> I debug the code and found couple of facts,
> <p></p>
> 1) AjaxStateHolder class uses ContextInitParameters class to rely on the
> no. of views to store in a session and expects a new context param '
> com.sun.faces.numberOfViewsInSession ' to be declare in the web.xml.
> <p></p>
> Now, we can explains what happens is while doing login browser sends up
> lots of request to server for page as well as for every image which is
> being displayed, or style sheets or js files etc.
> <p></p>
> And, sever stores up each request generated view in the same 'views' list
> which it is holding for pages. So, images etc are replacing the page view
> in the list for the first time as there were around total 25 requests are
> generating in our case for the cleaned browser.
> <p></p>
> After this, we do login second time and browser does not send separate
> requests for images and css as those are cached at browser end, so pages
> works fine because only one view (actual view for the page) get stored and
> it is available when it is required in immediate post back request.
> <p></p>
> <u>Proposed Solution 1:</u>
> <p></p>
> I am not sure, why AjaxStateHolder is storing every resource generated
> view in the same views list. Request, which are made for images, css and
> scripts should not be stored in the views state map.
> <p></p>
> Is this correct to store images, css and scripts in the same view state
> map or can I put a check on this chunk of code not to put images, css and
> scripts in the AjaxStateHolder view state map ? .
> <p></p>
> If it is really not required to store images, css and scripts in the same
> view state map, this will solve our problem completely.
> <p></p>
> Well, I didn't check the old version code for myfaces how it was handling
> this, whether it was storing the images and css etc in the same view state
> map or not but we never faced this problem in older version of my faces
> and rich faces.
> <p></p>
> <u>Proposed Solution 2 [Temporarily]:</u> I can set up
> com.sun.faces.numberOfViewsInSession variable to a high no. i.e. 25 which
> is the exact in our case and it will work fine. But, if I increase any
> image on the same first page and this problem could come again in front of
> us.

View this message in context:
Sent from the MyFaces - Users mailing list archive at

View raw message