From adffaces-user-return-514-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Tue Jul 18 22:01:24 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org Received: (qmail 60138 invoked from network); 18 Jul 2006 22:01:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Jul 2006 22:01:24 -0000 Received: (qmail 13119 invoked by uid 500); 18 Jul 2006 22:01:24 -0000 Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org Received: (qmail 12960 invoked by uid 500); 18 Jul 2006 22:01:23 -0000 Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-user@incubator.apache.org Delivered-To: mailing list adffaces-user@incubator.apache.org Received: (qmail 12951 invoked by uid 99); 18 Jul 2006 22:01:23 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jul 2006 15:01:23 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of darkarena@gmail.com designates 64.233.166.178 as permitted sender) Received: from [64.233.166.178] (HELO py-out-1112.google.com) (64.233.166.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jul 2006 15:01:22 -0700 Received: by py-out-1112.google.com with SMTP id d42so21066pyd for ; Tue, 18 Jul 2006 15:01:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fFhsALjSQlOCVnA3hXoHIk/CGVt36gGZS5hTIGU/4QORmz9yyNovkxP6pFwqB6rUn4JRjVnSHl1LKdCHksd1dAcweY9PBQW6J3ClVj+6U/bxtRITalxXZ4lvabKA0/jrT1aufJNqN3i6KHH847P0h+Y5TqpqKU+d/K7jLT6PkU8= Received: by 10.35.70.2 with SMTP id x2mr60862pyk; Tue, 18 Jul 2006 15:01:02 -0700 (PDT) Received: from ?216.176.42.1? ( [24.8.126.164]) by mx.gmail.com with ESMTP id 55sm39751pyf.2006.07.18.15.01.01; Tue, 18 Jul 2006 15:01:02 -0700 (PDT) Message-ID: <44BD5A19.6070204@gmail.com> Date: Tue, 18 Jul 2006 16:00:57 -0600 From: Scott O'Bryan User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: adffaces-user@incubator.apache.org Subject: Re: PPR and session timeout References: <44BC6F9E.4010603@corp.peace.com> <467251f60607180005w3d207476k50e5099ee97a7709@mail.gmail.com> <44BD1C85.70703@gmail.com> <467251f60607181401g75feac2ex279f635e70cf2810@mail.gmail.com> <44BD4F70.2080507@gmail.com> <37699f4d0607181425m2b4edcebhe0875c115e99e1f@mail.gmail.com> <37699f4d0607181427o1b1ddbcdt242fb905263afb79@mail.gmail.com> <467251f60607181439k1f771470n64acba03c69e9dd1@mail.gmail.com> In-Reply-To: <467251f60607181439k1f771470n64acba03c69e9dd1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Oooohhh. You're trying to prevent the session from timing out? You can use the poll component I suppose or you can set your server up so that sessions don't time out for a REALLY long time. You probably want them to time out eventually. Scott Cosma Colanicchia wrote: > Venkata, > > maybe I'm not getting your point, by in my script I'm trying to avoid > a "full page refresh". As I'm trying to keep my app as "session > timeout-proof" as possible, I use full client state saving and almost > all my managed bean are request scoped. Said that, I want the original > request parameters (so including the serialized component tree state) > to pass throught the login process, and because that was a PPR > requests I cannot simply load it as it was the main page (PPR response > seems to me to be potentially incomplete, only including the required > html elements and the code to replace them in the outer window). Even > knowing exactly what makes a request a "PPR" one, I'm not sure that it > is possible to safely revert it to a full request. > > So my solution was to simply have the login page showed someway, but > without breaking the usual PPR process, so the popup that submit > itself again into the _pprIFRAME. I had no full success with it, > because sometimes after the login the original action (a list sort, > for example) doesn't get executed, and the user must click again. I've > not researched the reasons of this. > > Regards > Cosma