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
