Re: [REVIEW/632] Server-side state saving sensitive to model changes

From: Adam Winer <>
Date: Tue, 11 Sep 2007 12:39:45 -0700

I'm fairly confident the spec says nothing. It also
does not say that server-side and client-side
state saving have precisely the same semantics - they
never have, not in 1.0, not in 1.1, and not now.
(They're closer in 1.2 than they were in 1.0.)

I'm far from convinced this is a really important
compatibility issue, and suspect that requiring
serialization will in fact break some developers
that are (mistakenly) storing unserializable objects
on their components.

In fact, I'm nearly certain that you'll break a lot
more applications than you'll fix.

-- Adam

Michael Youngstrom said the following on 9/11/07 12:27 PM PT:
> I'm curious how this issue looks from a spec perspective? Does the
> spec imply or say anything to the effect that values stored in the
> view are isolated from change beyond that view? If the spec says
> nothing then lets look at this from the perspective of the next spec
> release. In the next spec release will we have a requirement for
> component developers to clone mutable values before storing them in
> the view? I would say no. I think that would be a confusing
> requirement to place on component developers. I know component
> developers right now are definitely not cloning mutable values placed
> in the view.
> I think compatibility, interoperability, and ease of component
> development should be the default over performance. This is the main
> reason why I think serialize should be on by default. If the user
> wishes they can turn this off to gain greater performance at the risk
> of broken functionality.
> So how do we make this decision? An RI group vote?
> Mike
> On 9/11/07, Ryan Lubke <> wrote:
>> Ed Burns wrote:
>>>>>>>> On Fri, 07 Sep 2007 11:32:22 +0200, "Jesse Alexander (KSFH 323)" <> said:
>>> JA> +1 from me too on not making the serialization default. Serialization is
>>> JA> way too costly.
>>> I cast my lot with Herr Jesse and Mr. Winer. I too would like to see a
>>> quantitative rationale, other than parity with the client side model.
>> Performance issues aside (which we know there will be a decrease in
>> performance
>> when this option is enabled), a JSF application should be have the same
>> when using
>> the default state manager no matter what option is selected.
>> For what it's worth, it seems MyFaces serializes server state by default
>> [1]. So a SEAM
>> application on MyFaces will behave the same no matter the state saving
>> mode.
>> I'm still torn on this issue. I think the correct course of action is
>> to enable the serialization by default,
>> but looking at the MyFaces benchmarks, performance is nearly halved in
>> this case and I really don't
>> know how often the case Mike is reporting will happen. Perhaps it will
>> become more common
>> as more folks move to SEAM?
>> [1]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: