STATE_SAVING_METHOD

[James Ellis]

What does changing the STATE_SAVING_METHOD in web.xml really do? I have been playing around with it and I know that when STATE_SAVING_METHOD="client" that any beans referenced from jsp must implement serializable, but I am not sure why. Where is the state being saved? In a session variable? If so how can you specify "session variable on client" versus "session variable on server".

Is there any benefit to one way or the other?

[Marc Peabody]

By my understanding of it...

When it is set to "client", try View Source on one of the pages in your browser. You should find the state saved as a hidden field in the form. I think the whole view gets encrypted into that String, which is why it all must be Serializable.

[Varun Khanna]

Originally posted by James Ellis:
What does changing the STATE_SAVING_METHOD in web.xml really do?

Helps you in deciding where you want to save the state of your application i.e. where you want to save UIViewRoot.

I have been playing around with it and I know that when STATE_SAVING_METHOD="client" that any beans referenced from jsp must implement serializable, but I am not sure why.

As per my knowledge this is incorrect. Implementing serializable isn't a requirement. Also, to save bean's state at client side, implementing serializable won't solve your problem. You will be required to implement saveState() and restoreState() methods too and probably few more things.

Where is the state being saved? In a session variable? If so how can you specify "session variable on client" versus "session variable on server".

At "server" it is stored at HttpSession, at "client" it is stored in hidden variable.

Is there any benefit to one way or the other?

In a distributed environment, You will probably prefer saving state to client.
[ September 13, 2005: Message edited by: Varun Khanna ]

[Marc Peabody]

Originally posted by Varun Khanna:

As per my knowledge this is incorrect. Implementing serializable isn't a requirement.

The MyFaces implementation looks like it uses 64-bit encryption to save both the view and state as hidden fields. To my knowledge, an object must be Serializable to be encrypted.

For what it's worth, I tried finding implementation details for "client" in the JSF spec but couldn't find any. Looks like that's up to the implementation to decide but I can't think of any way to handle this other than saving everything to hidden fields on every page (as does MyFaces).

[Gregg Bolinger]

Originally posted by Marc Peabody:
For what it's worth, I tried finding implementation details for "client" in the JSF spec but couldn't find any. Looks like that's up to the implementation to decide but I can't think of any way to handle this other than saving everything to hidden fields on every page (as does MyFaces).

Yes, client state is up to the vendor to implement. And for what this is worth, ASP.NET calls it View State and it is hidden encrypted fields.

[Varun Khanna]

Originally posted by Marc Peabody:


The MyFaces implementation looks like it uses 64-bit encryption to save both the view and state as hidden fields. To my knowledge, an object must be Serializable to be encrypted.

For what it's worth, I tried finding implementation details for "client" in the JSF spec but couldn't find any. Looks like that's up to the implementation to decide but I can't think of any way to handle this other than saving everything to hidden fields on every page (as does MyFaces).

Sorry, I couldn't understand your point.
Do you mean in myfaces backing bean has to be serializable or one can serialize it through some configuration?

In which scenario would you prefer your backing bean to be serialized ?

[Varun Khanna]

Okay, just did a quick Search and found this :

http://forum.java.sun.com/thread.jspa?forumID=427&threadID=508703

[Marc Peabody]

Originally posted by Varun Khanna:
Okay, just did a quick Search and found this :

http://forum.java.sun.com/thread.jspa?forumID=427&threadID=508703

Looking at the MyFaces source tonight, I was surprised to see that it "Serializes" even when saving in session mode and only the values inside the components (or whatever gets added to the Object[] in the component's saveState method) get Serialized. So the Backing Beans should never need to be Serializable (Varun's correct, go figure) as long as you aren't placing them inside of a component's value.

Again though, these details (as asked by the original question of this thread) are left to the implementor. This is just how MyFaces does things... as far as I can tell.

[Kevin Galligan]

I didn't follow the link. However, I'd like to try and clear up some things.

The state being save isn't your appliction's code state. Its the state that faces retains. You need to read the chapter on this in whichever book you have (buy a book, if you have not. JSF in Action or the O'reilly book I'd recommend). Basically, jsf builds its own interface components, and these bind to values and functions on your objects. When it saves state, its saving its own objects' state. Your objects' state is up to you. If you use session scope, your objects stick around, but you need to be careful with sessions.

As for benefit of client vs. server, there's no clear winner. If there were, there would probably be only one option.

Session: keeps state on server, which reduces network traffic and processing when rebuilding state. Can't use back button, and when developing you can run into some strange issues.

Client: Can use the back button. A little more consistant for development. Increases network traffic to write state to client, and processing when submitted.

Personally, I use client state. This is due entirely to the back button issue. In version 1.2, there is supposed to be some better back button support. I haven't read much on this, but I think it only keeps your app consistant. It doesn't actually make the back button 'work' with server state. For internal applications I might wind up using server, as I can dictate how the application is used. For external applications, I'd probably go with client. Its hard to tell customers that they can't use a back button or refresh. Imagine Dell telling you can only use your new computer's mouse on Tuesday's. Its not that bad, but its not the best conversation.

We got into a performance discussion when talking about this not too long ago. I think that if you're building an app for huge numbers of concurrent users, or a big public site, and your screens are going to be critical path, JSF might not be the best thing for you. For the other 99.99% of applications out there, some performance hit might be eclipsed by the development time savings.

However, the jury is still out as to if you'll be more productive with JSF. I'm still figuring that out...

[jack catler]

I know this thread went silent a while back, but it is the topic of interest for me.

One question, leading on from Kevin's summary (which I found very helpful...), does that mean (in the end) a bean DOES need to impliment Serializable to allow the use of STATE_SAVING_METHOD on either Client or Server ?

Thanks!

[Gregg Bolinger]

Originally posted by jack catler:
I know this thread went silent a while back, but it is the topic of interest for me.

One question, leading on from Kevin's summary (which I found very helpful...), does that mean (in the end) a bean DOES need to impliment Serializable to allow the use of STATE_SAVING_METHOD on either Client or Server ?

Thanks!

Any class that could potentially be persisted needs to implement Serializable. This is not only true in JSF but for java in general.