My JSF Books/Videos My JSF Tutorials OmniFaces/JSF PPTs
JSF 2.3 Tutorial
JSF Caching Tutorial
JSF Navigation Tutorial
JSF Scopes Tutorial
JSF Page Author Beginner's Guide
OmniFaces 2.3 Tutorial Examples
OmniFaces 2.2 Tutorial Examples
JSF Events Tutorial
OmniFaces Callbacks Usages
JSF State Tutorial
JSF and Design Patterns
JSF 2.3 New Features (2.3-m04)
Introduction to OmniFaces
25+ Reasons to use OmniFaces in JSF
OmniFaces Validators
OmniFaces Converters
JSF Design Patterns
Mastering OmniFaces
Reusable and less-verbose JSF code

My JSF Resources ...

Java EE Guardian
Member of JCG Program
Member MVB DZone
Blog curated on ZEEF
OmniFaces is an utility library for JSF, including PrimeFaces, RichFaces, ICEfaces ...









[OmniFaces Utilities] - Find the right JSF OmniFaces 2 utilities methods/functions

Search on blog

Petition by Java EE Guardians


vineri, 6 martie 2015

JSF 2.2 support stateless

The notion of being stateless is pretty confusing, because every application must maintain some kind of state (for example, for runtime variables). Generically speaking, a stateless application will follow the rule of a state per request, which means that a state's lifecycle is the same as the request-response lifecycle. This is an important issue in web applications, where we need to use session/application scope that, obviously, breaks down the notion of stateless.
Even so, one of the most popular features of JSF 2.2 consists of stateless views (and is actually available starting with Version 2.1.19). The idea behind this concept assumes that JSF will not save/restore the view state between requests and will prefer to recreate the view state from the XHTML tags on every request. The goal is to seriously increase performances: the gain time used for the save/restore view state, more efficient usage of server memory, more support for clustered environments, and the prevention of ViewExpiredExceptions. So, JSF developers have certain requirements of the stateless feature. Nevertheless, it seems that the stateless feature doesn't affect too much of the time used for saving/restoring the view state (this is not expensive, especially when the state is saved on a server session and is not going to be serialized) and memory performances. On the other hand, when an application is deployed on several computers (in clustered environments), the stateless feature can be a real help because we don't need session replication (refers to replicating the data stored in a session across different instances) and/or sticky sessions (refers to the mechanism used by the load balancer to improve efficiency of persistent sessions in a clustered configuration) anymore. For stateless applications, the nodes do not need to share states, and client postback requests can be resolved by different nodes. This is a big achievement, because in order to resolve many requests, we can add new nodes without worrying about sharing the state. In addition, preventing ViewExpiredException is also a big advantage.

Note Stateless views can be used to postpone session creation or dealing with big (complex) component trees that implies an uncomfortable state.

Starting with JSF 2.2, the developers can choose between saving the view state and creating stateless views in the same application, which means that the application can use dynamic forms in some views (stateful) and create/recreate them for every request in other views (stateless). For a stateless view, the component tree cannot be dynamically generated/changed (for example, JSTL and bindings are not available in the stateless mode) and resubmitting forms will probably not work as expected. Moreover, some of the JSF components are stateful, which will lead to serious issues in a stateless view. But, it is not so easy to nominate those components and the issues, since their behavior is dependent on the environment (context). Some specific tests may be helpful.
In order to write a JSF stateless application, you have to design everything to work only with the request scoped bean. In some cases, we can use different tricks to accomplish this task, like using hidden fields and special request parameters for emulating a session. While session and application beans will break down the idea of stateless (even if it is possible to use), the view bean will act as request beans.

Programmatically speaking, defining a view as stateless is a piece of cake: just add the attribute named, transient to the <f:view> tag and set its value to true. Note that in order to have a stateless view, the presence of <f:view> tag is mandatory, even if it doesn't have any other use. Each stateless view of an application needs this setting because there isn't a global setting for indicating that the stateless effect
should be applied at the application level.

<f:view transient="true">

When a view is stateless, the javax.faces.ViewState value will be stateless, as shown in the following screenshot:
You also may be interested in:

Niciun comentariu :

Trimiteți un comentariu


Postări populare

OmniFaces/JSF Fans

Visitors Starting 4 September 2015

Locations of Site Visitors