I think there is definitely some confusion going on here. I am not 100% sure I am understanding you fully, so please forgive any possibly incorrect conclusions, but let me see if I can address your issues. Please also note that I have only worked with servlets and not portlets.
State saving: CLIENT vs. SERVER are the same thing in terms of functionality. The state that is saved is the data that is returned from the UIComponent.saveState() method. This information is used during the RESTORE_VIEW phase to reconstruct the component tree. That reconstructed component tree is then iterated over for decoding, validating, updating and then rendering. This state has *nothing* to do with backing bean scope. The choice of CLIENT vs. SERVER is a choice of performance. CLIENT side state means that the component tree's state is serialized into an <INPUT TYPE="hidden" /> HTML control that is submitted to JSF via the FORM submittal. SERVER side state means that up to X views (20 by default), the state is saved into the user's HttpSession object. When the user submits a view, the server attempts to locate the state for the component tree in the user's session. If found, the component tree is rebuilt and de-serialized from this information. So the performance choice is a harder hit on the network and the client (client side state) or a much larger hit on the application server's RAM/heap (server side state) Managed, aka Backing, Bean state The JSF spec supports request and session, and a few 3rd parties have added the support for an in between state of conversation. These beans live in the faces context. For request beans, the beans are stored into the request object and therefore released and eventually garbage collected once the request is finished. They are created the first time that someone accesses them using the VariableMapper (EL expression). Session beans are stored into the HttpSession and therefore should implement java.io.Serializable so that in a clustered environment, these beans can be used from each server within the cluster. The beans, like request beans, are created on first use, but since they are stored in the HttpSession, they are never re-created (except of course when the user's session expires due to programmatic termination or inactivity timeout, or the user deletes the cookie). Okay, with all that iterated through, let me try to address your comments...
I will list 2 scenarios: I have a jsf-portlet application for non authenticated users, say something like user registeration. Then for obvious reasons, I cannot have anything in session scope.
You can use session scope just fine, why do you think you can't? At least with servlets, an HttpSession is keyed by a session ID that is typically saved in an in-memory cookie in the browser. The user does not have to be in HTTPS or authenticated for servlet sessions to work (it is tied to the browser window, not the user). I use conversation scope beans with JBossSeam with user registration wizards (I use conversations, because I prefer to have my beans released after the user has finished registering instead of waiting until the HttpSession is destroyed -- otherwise my user's session would take up too much RAM). FYI, If the user has turned cookies off, the HttpSession key is appended to the query string.
I have to have javax.faces.STATE_SAVING_METHOD as client. Otherwise I do not get user entered values.
Why? If you used server state, the view is tied to the user's http session (cookie based remember). Either client or server would work here. The only time you loose the form's data (user entered information) is if you do not submit the form (like <h:outputLink/> instead of using <h:commandLink/>)
Second- For a similar application for logged in users, I can have javax.faces.STATE_SAVING_METHOD as server. And when it is server, jsf implementation is storing the state information in session on server.
Same answer as before, doesn't matter if the user is logged on or not, sessions are browser window based, not user based.
Now it puzzles me when they say that they save the state in session. If it is so, then why would JSF reinitialize when a request comes from outside jsf application, and it is neither initial nor postback request.
Session backing beans are stored in the session. The serialized views are also stored there only if you are using server side state. When the user does a POST back to the server (with server side state saving), the JSF engine attempts to see if that is a submit back to the same view. If so, it attempts to restore the view from the HttpSession of the user. If the view is not found, a new view is created (I'm pretty sure, but I didn't double check with the spec). -Andrew
