Hi When JSF was released I was concerned that if each component is stored as an object in the session context I would have to replicate hundreds of objects if I wanted High Availability and Transparent Failover for my web applications. In my job we create many web applications that are executed in many app servers. So I decided to continue developing with other frameworks and wait to see what happened with JSF. Now that there are many JSF implementation is this a real issue?

Session replication is more low level issue than JSF. Which means who ever is offering the session replication to you does not know what framework you are using to build the application . So it does not matter whether it is JSF or Struts or any of your home grown. If your application fulfills minimal needs the session will be replicated seamlessly.

Yes I understand that this is a low lever function, but, the heavy use of session objects in JSF will require heavy replication between servers of tis objects. So the question is, in the real world, has this been an issue for an enviroment with 5 to 10 servers?

Now you put the correct query. Check the type of replication you are using. If you are replicating across the cluster I assume this definitely will be a over head where as in master slave replication mode it should be fine.

Way late in this conversation. I just wanted to point out that JSF has two state saving mechanisms: Servier and Client. If you are using Client, the object tree is saved (encoded) into the HTML page eliminating need to save sate in the session.
Also note that you "could" replace the state saving mechanism with a distributed cache implementation. Certainly there are pro's anc con's to state saving.
I would also point out that the footprint of the view component tree is not typically as much of an issue as the state of the controllers and such that often need to sit behind it.

I just wanted to point out that JSF has two state saving mechanisms: Server and Client. If you are using Client, the object tree is saved (encoded) into the HTML page eliminating need to save sate in the session.
Also note that you "could" replace the state saving mechanism with a distributed cache implementation. Certainly there are pro's and con's to state saving.

So, if I understand correctly: I can shuttle the object tree back and forth on every server request (including, I assume, partial submits); or I can use the session-replication mechanism (which will most likely become an overhead); or I can replace the built-in mechanism by a distributed cache? That's it? No other option? Joy!