JSF Component state Save process

JSF can save state of component tree in either session or on clients machine inform of serialized data .
While creating component tree JSF creates a key and keep all objects of component tree as UIViewRoot in session with against it.For next JSF request it will use same key to restore that view 🙂
For client side saving has performance issues like it has to serialize whole tree and write it in response ship in form of gzip to client.Next time when same client make JSF request from same page it de-serialize it and inflate all objects in corresponding state .

Setting for state saving is done in web.xml.

Server side state saving is where the component tree and all component state are stored within the user’s session. This entry within the session is tracked by writing a key in the response that is used to lookup the entry on subsequent post-backs.

Client side state saving doesn’t leverage the server side session mechanism at all, instead, the component tree and state will be serialized using Java Serialization, GZIP compressed (at least that is the default), Base64 encoded, and written to the response. When a post-back occurs, the encoding process will be reversed which will result in the tree and state we started with.

Setting in web.xml

  <context-param>
<description>State saving method: 'client' or 'server' (=default). See JSF Specification 2.5.2</description>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>

Why does JSF need to save the state of UI components on the server side ?

Because HTTP is stateless and JSF is stateful. The JSF component tree is subject to dynamic (programmatic) changes. JSF simply needs to know the exact state as it was when the form had been displayed to the enduser, so that it can successfully process the whole JSF lifecycle based on the information provided by the original JSF component tree when the form has been submitted back to the server. The component tree provides information about the request parameter names, the necessary converters/validators, the bound managed bean properties and action methods.

As a logged-in user on the application navigates though pages, will the state of components keep on accumulating on the server?

Technically, that depends on the implementation. If you’re talking about page-to-page navigation (just GET requests) then Mojarra won’t save anything in session. If they are however POST requests (forms with commandlinks/buttons), then Mojarra will save state of each form in session until the max limit. This enables the enduser to open multiple forms in different browser tabs in the same session.

Or, when the state saving is set to client, then JSF won’t store anything in session. You can do that by the following context param in web.xml:

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

It will then be serialized to an encrypted string in a hidden input field with the name javax.faces.ViewState of the form.

Happy learning with Vinay in techartifact

ADF_FACES-30107: The view state of the page has expired. Load the page again.

Requirment- Resolving ADF_FACES-30107: The view state of the page has expired. Load the page again.
ugly error actually.- you don’t know what went wrong- and you will see a very long error message like
ADF_FACES-30107: The view state of the page has expired. Load the page again………………………………………………………………………..

What’s the problemFirst understand , why we get this error – The ViewExpiredException will be thrown whenever the javax.faces.STATE_SAVING_METHOD is set to server (default) and the enduser sends a HTTP POST request using or or some valueChangeEvent on a view, while the associated view state isn’t available in the session anymore. The view state is identified by a hidden input field javax.faces.ViewState of the . With the state saving method set to server, this contains only the view state ID which references a serialized view state in the session. So, when the session is expired for some reason (either timed out in server or client side, or the session cookie is not maintained anymore for some reason in browser, or by calling HttpSession#invalidate() in server), then the serialized view state is not available anymore in the session and the enduser will get this exception.With the state saving method set to client, the javax.faces.ViewState hidden input field contains instead the whole serialized view state, so the enduser won’t get a ViewExpiredException when the session expires.

In the oracle documentation this error states-

ADF_FACES-30107: The view state of the page has expired. Reload the page.
Cause: The UI state of the view has expired, either because the back button has been used too many times, too many page submissions have occurred on ther pages, or because of an underlying bug in the view code.
Action: The application using ADF should install an ADFc error handler for JSF ViewExpiredExceptions, or configure the org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS web.xml parameter to a larger value.
Level: 2

Type: ERROR

Impact: Logging

How to resolve this – Find for the org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS in web.xml as context parameter . If it not set as it happened to my application. Set this parameter and put value.Sometimes,it will not work for value for 15 to 20. I set it as 500.This mean , it can handle this much page submission for the pages.

Great.After reading this ,you resolved the error.

Happy coding with Vinay kumar in techartifact……