Ed Burns wrote:
>>>>>> On Wed, 12 Sep 2007 09:10:36 -0600, Michael Youngstrom <youngm_at_gmail.com> said:
>>>>>>
>
> MY> So, the the votes are in and it looks like the decision is to not
> MY> serialize the server state. However, does this snippet from the spec
> MY> make our vote irrelevant?
>
> MY> Section 7.6.3: when talking about server state management says:
>
> MY> "The default implementation Serializes the view in both the client and
> MY> server modes. In the
> MY> server mode, this serialized view is stored in the session and a
> MY> unique key to retrieve the
> MY> view is sent down to the client. By storing the serialized view in the
> MY> session, failover may happen using the usual mechanisms provided by
> MY> the container."
>
> MY> It seems pretty explicit here. This is probably why Myfaces
> MY> serializes the view by default in "SERVER" mode. Does this snippet
> MY> from the spec change our decision at all? If we decide to ignore this
> MY> snippet of the spec we should probably let MyFaces know so that they
> MY> don't have to serialize the view by default.
>
> Ah yes, I recall now why we put that in there. It was to guarantee that
> failover would work in clustering server scenarios.
>
> I propose we modify the spec to introduce a config param that turns it
> on, but have it off by default. Should I take that to the EG?
>
> Ed
>
>
I think this section of the spec is poorly worded.
It docs for saveView() also state that the object returned must be
serializable but not already serialized.
This was to handle HA in the server side case. It doesn't make any
sense to me to Java serialize the view before HA handles the
serialization.
I believe in all cases "serialized view" is not Java Serialization, but
the act of saving the component tree and state.