You are kidding now right?
Anyhow, the seam standard scope is event scope. So you will
beginit when you enter the page and
endit when you leave per default. It is only if you start a long running conversation that the magic of seam kicks in.
Err... well as far as i know the event scope
beginwhen you enter the page and
endsin the end of the request. Btw, the event scope IS the request scope of the JSF.
Components associated with the event context are destroyed at the end of the request, but their state is available and well-defined for at least the lifecycle of the request.
So well.. my problem is still in the air. From my point of view, now the page scope is potentially more dangerous than the session scope.
From the Seam API doc:
The page context allows you to store state during a request that renders a page, and access that state from any postback request that originates from that page. The state is destroyed at the end of the second request. During the RENDER_RESPONSE phase, the page context instance refers to the page that is about to be rendered. Prior to the INVOKE_APPLICATION phase, it refers to the page that was the source of the request. During the INVOKE_APPLICATION phase, set() and remove() manipulate the context of the page that is about to be rendered, while get() returns values from the page that was the source of the request.
Yah, i read that too Ingo, but the strange thing is this in the FAQ.
From the Seam FAQ - When does the page context get destroyed?
The page scope is indistinguishable from the UI component tree. Therefore, the page context is destroyed when JSF removes the UI component tree (also called the view) from the session. However, when this happens, Seam does not receive a callback and therefore the @Destroy method on a page-scoped component never gets called. If the user clicks away from the page or closes the browser, the page context has to wait to get cleaned up into JSF kills the view to which it is bound. This typically happens when the session ends or if the number of views in the session exceeds the limit.
Well i tried to see the @Destroy in action in a page-context Scoped component... i opened 20 tabs in my firefox, so at least 5 views would expire (i think), but it didnt work. So for now the Page Scope look's like a session-scope that multiplies infinitely until the session expire.
So.. any ideas? Is the page context more dangerous than the session scope? What could i do?
You can control how many views are kept in the session using the following in pages.xml
<context-param> <param-name>com.sun.faces.numberOfViewsInSession</param-name> <param-value>5</param-value> </context-param> <context-param> <param-name>com.sun.faces.numberOfLogicalViews</param-name> <param-value>5</param-value> </context-param>
The glassfish wiki has a description of each of these parameters here