where did you get the number 15??  that seems totally random.  it's not @PageScope, it's @Scope(ScopeType.PAGE).

page scope is a scope that lasts less in duration compared to conversation scope but longer than event (request) scope.  in certain situations, it makes sense to use it.  For example, you may have a @DataModel on a List scoped to page such that the context variable is outjected to page scope with fresh data per xhtml via @Factory (tied to the @DataModel context variable).

SiA book:

JSF has always supported a page scope, which is an unofficial classification of the attributes
stored in the view root of the JSF UI component tree. Seam recognizes these attributes
as first-class context variables and exposes them via the Seam page context. The
page context is capable of propagating data from the Render Response phase of the JSF
life cycle through at least the ensuing Invoke Application phase on a postback, then on
to the Render Response phase if the same view is rendered again without a redirect. This
cycle continues for as many times as the same UI component tree is restored (as a result
of a postback), and is only terminated by a navigation event that occurs prior to the Render
Response phase. You may have used this scope in a less formal way if you have ever
included the <t:saveState> component tag from the MyFaces Tomahawk component
set1 in your application. The benefit of using Seam’s page context is that you don’t tie
the state logic to the view.

15 is the right number because the default value of com.sun.faces.numberOfViewsInSession is 15

Adrian Mitev wrote on May 25, 2009 22:32:


15 is the right number because the default value of com.sun.faces.numberOfViewsInSession is 15

A ha!  thx for the explanation.

relevant thread: http://forums.sun.com/thread.jspa?threadID=5370244

so does that mean if you click a HtmlCommandButton which calls a backing bean action handler method that returns void (thus postback) more than 15 times when javax.faces.STATE_SAVING_METHOD = server, then you will see some JSF-related exception?

Why doesn't the RI just flush the old states one-by-one insteading of blowing up like that?

The default is:

<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>

as per SiA.

I wonder if there is a JIRA or mod for this problem/design in JSF 2.0?

No, to make it blow up you need to have viewed 15 different pages (i.e. 15 different GET requests), when this happens the oldest view will get ejected, and you will get an exception if you try and post back to that view.

In main.xhtml for the booking example, I just submitted the form twenty or more times and no problems.  Nothing in web.xml about javax.faces.STATE_SAVING_METHOD so that means it's storing state on server.

No, to make it blow up you need to have viewed 15 different pages (i.e. 15 different GET requests), when this happens the oldest view will get ejected, and you will get an exception if you try and post back to that view.

ok, but still, what if you have a very large JSF app with more than 15 pages?  that still seems like a possible limitation.  I guess the value is configurable in web.xml so you just increase it (and take up more server memory?)

I still find it amazing that the web.xml does not allow you to read values from a DB or properties file.  Yes, I know, limitation of XML most likely but still, it's EE 6 now.

Will this hard-coding limitation ever be fixed in the servlet spec somehow?  I guess alternatively you could write a Seam components that is marked @Startup and a @Create method that programmatically sets the variable you need to config...

[sorry, that was off-topic but it was really bothering me last week]

I'm sure the Seam core devs would say that using the page scope in certain scenarios is not bad practice.

Here's an example from the seambay example:

@Name("memberAction")
@Scope(EVENT)
public class MemberAction implements Serializable
{
   private static final long serialVersionUID = -8233305696689620298L;

   private String memberName;   
   
   private Account selectedMember;
   
   @In 
   EntityManager entityManager;   
   
   @Factory(value="selectedMember", scope=ScopeType.PAGE)
   public Account getSelectedMember()
   {
      if (selectedMember == null && memberName != null)
      {
         selectedMember = (Account) entityManager.createQuery(
            "from Account where name = :name")
            .setParameter("name", memberName)
            .getSingleResult();             
      }
      
      return selectedMember;
   }    
   
   public String getMemberName()
   {
      return memberName;
   }
   
   public void setMemberName(String memberName)
   {
      this.memberName = memberName;
   }   
}

It does not really matter how many pages your jsf app has, if you want you can view this behavior in a web app with a single page, open the the site in two browser windows, and then refresh one of them 15 times, then try and use the other window and you will get an error.

Client side state saving is an alternative, however it does require that anything you put in page scope is serialisable, and you cannot trust any objects state, as it possible for the client to modify it.