According to this blog JSF is going stateless . Isn't the whole point of using JSF is that it makes saving and restoring state a chore . What is the point of JSF becoming stateless ? Can you please provide an example where this can be useful .
What is the usefulness of statelessness in JSF?
First of all, I would like to clarify that JSF isn't exactly "going stateless" at its whole own. JSF just adds a new feature enabling the developers to create stateless views/forms on demand.
State saving is particularly helpful in dynamically manipulated forms with e.g. conditionally ajax-rendered parts. It remembers the state of the form across ajax based postbacks. In other words, it are those forms where you absolutely need a view scoped managed bean instead of a request scoped managed bean. In case of static forms tied to a request scoped bean, the state could easily be recreated on a per-request basis based on the view file and hence doesn't necessarily need to be saved.
State saving has in case of server side state saving management however a cost in terms of server memory and session creation. Also, it has the additional disadvantage that a ViewExpiredException would occur during a postback while the session has expired. All of this can be solved by setting the state saving management to client side. But this has in turn a cost in terms of network bandwidth and lower performance due to serialization.
For example, in case of large websites covering a "public" and "restricted" section, you'd like to postpone session creation until the user has actually logged in. However, if you have a JSF login form on the public part, then the session would still be created by just accessing that page. This is an unnecessary cost if the form has basically no dynamic state at its own and is tied to a request scoped bean.
True, this cost is negligible if you have state of the art hardware, but it's not negligible if you have relatively a lot of visitors and/or relatively poor hardware. In that case, measuring is knowing. Also, it is not always possible to go fully stateless, you'd lose the benefit and experience of having dynamically manipulated views/forms. You could however theoretically maintain the state on a per-request basis by fiddling with hidden input fields and/or custom request parameters.
Noted should be that statelessness has an additional disadvantage that it's theoretically more easy to perform a CSRF attack if there's an open XSS hole. Fortunately, with JSF2/Facelets it's already very hard to have a XSS hole. The only way to get that is to use a <h:outputText escape="false"> to redisplay user-controlled data.
See also:
The point is only to maintain state when there is real state to maintain.
One of the big issues with JSF has been scaling out.
You basically have had two choices with JSF:
store state on server - pros: faster response time; cons: you need boot loads of memory to handle more than about 2-300 users "just browsing" eg before they login or add anything to the shopping cart
store state on client - pros: removes the memory limit; cons: increases the server bandwidth as the component tree has to be sent to the client each time
Stateless is supposed to ensure that JSF can be used to serve content efficiently while the user has no state required to be maintained.
There are additional refinements, such as allowing the component tree to be reused where it makes sense, but the idea is to let the app scale better.
Your main point of scaling is correct, but the explanation not. JSF isn't that bad as you seem to think/imply. Static JSF pages without forms don't generate any state at all. Only when you've a page with a
<h:form>, you generate state. Plus, since JSF 2.0 not the "whole component tree" is been saved, only the dynamic part of it will be saved (input components, etc, but not e.g. labels/texts). –
Byyourleave Perhaps I should have highlighted that diff between 1.2 and 2.0 –
Karlotte
The question was tagged JSF2, so we would assume that the answer is targeted on JSF2. Perhaps you had JSF 1.x in mind while answering and never really have worked with JSF2 which was already out more than 3 years ago? –
Byyourleave
When I was using JSF 2.0 I found that it was caching some state too... though that could just have been Apache MyFaces at the time... –
Karlotte
Lets say I would like to reduce statelessness on the V part of MVC, and I am making a ecommerce website with shop items. Wouldn't the part of user being logged in NEED to have state no matter what with JSF? (And we could keep the part of a non user just "browsing") stateless to save server memory? Is this a correct way of looking at statelessness in JSF? Could we somehow keep the user being logged in stateless? –
Pironi
© 2022 - 2024 — McMap. All rights reserved.
For example, in case of large websites covering a "public" and "restricted" section ...if we wrap that login form around<f:view transient="true">, would it solve the problem u mention? – Rhomboid