I'm still on the JSF learning curve, but I believe we're talking here
about saving the UIComponent tree state, and that that is done via a
custom approach in JSF.
Firstly the JSF framework saves the classnames of the UIComponent object
tree, so that it can build an identical tree (but of new UIComponent
instances) when it needs to.
Then each UIComponent object in the tree has its "saveState" method
called, which is expected to return an object array containing its
state. The UIComponent doesn't use java serialization; components with
no children typically just store the primitive values of its member
fields into an object array. Note that saveState can't use normal
serialization because the "component tree" has already been rebuilt by
the framework and that the return value of saveState is used to
*repopulate a particular UIComponent instance* (the one restoreState is
called on) rather than creating a UIComponent tree as deserialisation
would do.
I don't know why this custom approach was used.
If I'm on the wrong track, please let me know.
Regards,
Simon
Adam Winer wrote:
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]
<mailto:[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] <mailto:[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
