Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 3252 invoked from network); 19 Oct 2005 08:04:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Oct 2005 08:04:48 -0000 Received: (qmail 58385 invoked by uid 500); 19 Oct 2005 08:04:45 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 58339 invoked by uid 500); 19 Oct 2005 08:04:44 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 58328 invoked by uid 99); 19 Oct 2005 08:04:44 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Oct 2005 01:04:44 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mbroekelmann@googlemail.com designates 64.233.184.195 as permitted sender) Received: from [64.233.184.195] (HELO wproxy.gmail.com) (64.233.184.195) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Oct 2005 01:04:44 -0700 Received: by wproxy.gmail.com with SMTP id i28so10575wra for ; Wed, 19 Oct 2005 01:04:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YGB+Z7Yc51VchMjIV1it7rCl27dcVZoJPqKHUCMhtKtISrRAD2/f6GJXzM0u574f55lMeHCmpxCdQ74j3aWBTaJIv3NG57DTCMPWBEsUjHAN8ytYFF3JDtmiVvlpfKhceACR8H5YCX33qwP2G6eTjNrdwC8Q6TTOkCfz62BFdZs= Received: by 10.54.110.17 with SMTP id i17mr139330wrc; Wed, 19 Oct 2005 01:04:22 -0700 (PDT) Received: by 10.54.77.14 with HTTP; Wed, 19 Oct 2005 01:04:22 -0700 (PDT) Message-ID: <9eb65db00510190104s1fc187bcw@mail.gmail.com> Date: Wed, 19 Oct 2005 10:04:22 +0200 From: =?ISO-8859-1?Q?Mathias_Br=F6kelmann?= To: MyFaces Development Subject: Re: Super! In-Reply-To: <6dac79b90510181306l3b070258m48ebbd65d4994683@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <5a99335f0510180823q1bfc5e2ahc15960158913a3bf@mail.gmail.com> <9eb65db00510180856g4f3dc52al@mail.gmail.com> <6dac79b90510181306l3b070258m48ebbd65d4994683@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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=B4t 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 : > 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