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