I´ve added two context parameters: org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION defines the number of the latest views stored in the session with a default of 20 (like RI)
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION if true (default) the state will be serialized to a byte array, otherwise it will not be serialized. IMO the last param should be used with care if it is true for development time and false for deployment. The component t:savestate may save the state of any complex statefull bean which may hold a state too. So this state will get shared between the views if it is not serialized. So expect a different behavior if switching this flag on a production system. 2005/10/20, Adam Winer <[EMAIL PROTECTED]>: > Ah, so you don't save the objects directly, you save the byte streams? > > That's excellent for development - it's a pain figuring out down the road > that one object way down deep isn't serializable, and only when you try > clustering right before going production :) - but seems like an unnecessary > performance hit at deployment time. Perhaps a flag to switch between the > two? > > -- Adam > > > > > On 10/19/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > > You are right the two objects in SerailizedView are serialized and put > > into the session. > > > > The instances of the server side state where not serialized before. > > This doesn´t affect the component instances since they are only > > referenced by class name in the state but it could have an effect on > > the state of the components. Some components may have statefull > > objects in their state (t:savestate for instance) > > > > The next thing is that clustering or a restart of the container is now > > better supported because the user will see a NotSerializeableException > > immediatly if a value of the state is not serializable. > > > > 2005/10/18, Adam Winer <[EMAIL PROTECTED]>: > > > What exactly do you mean by "the serialized view is now really > > > serialized (this was not the case before)"? Before, server-side > > > state saving (at least in 1.1 RI) was just stashing the UIViewRoot, > > > which dies for a bunch of reasons. I'm gonna guess that > > > you grab the SerializedView object with StateManager.saveState(), > > > and then save off its two components. > > > > > > -- > > Mathias > > > > -- Mathias
