From adffaces-issues-return-1793-apmail-incubator-adffaces-issues-archive=incubator.apache.org@incubator.apache.org Wed Feb 14 00:42:07 2007 Return-Path: Delivered-To: apmail-incubator-adffaces-issues-archive@locus.apache.org Received: (qmail 49853 invoked from network); 14 Feb 2007 00:42:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Feb 2007 00:42:07 -0000 Received: (qmail 18164 invoked by uid 500); 14 Feb 2007 00:42:14 -0000 Delivered-To: apmail-incubator-adffaces-issues-archive@incubator.apache.org Received: (qmail 18148 invoked by uid 500); 14 Feb 2007 00:42:14 -0000 Mailing-List: contact adffaces-issues-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-issues@incubator.apache.org Delivered-To: mailing list adffaces-issues@incubator.apache.org Received: (qmail 18124 invoked by uid 99); 14 Feb 2007 00:42:14 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Feb 2007 16:42:14 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of darkarena@gmail.com designates 66.249.82.224 as permitted sender) Received: from [66.249.82.224] (HELO wx-out-0506.google.com) (66.249.82.224) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Feb 2007 16:42:03 -0800 Received: by wx-out-0506.google.com with SMTP id i26so13987wxd for ; Tue, 13 Feb 2007 16:41:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Qea179IyRTALfKfpsQoiDYZZwkqzOMd+TkpiGsltcgUOaX7D76FbPnQ9iSrUgwQHeMQxBzfMFPWJigg7hf62mZ33BtxQNiX1gf0LGUS9htl0rHDcPoulVIyAIUPZEQwb4SgWb6ccxVyucVFfU5WyfZCMNT7wAWZBF4o7lODIJx8= Received: by 10.70.89.1 with SMTP id m1mr27585286wxb.1171413701657; Tue, 13 Feb 2007 16:41:41 -0800 (PST) Received: from ?152.177.50.1? ( [24.8.126.164]) by mx.google.com with ESMTP id 8sm77491wrl.2007.02.13.16.41.39; Tue, 13 Feb 2007 16:41:40 -0800 (PST) Message-ID: <45D25AC1.8080100@gmail.com> Date: Tue, 13 Feb 2007 17:41:37 -0700 From: Scott O'Bryan User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: adffaces-issues@incubator.apache.org Subject: Re: [jira] Updated: (ADFFACES-379) Configurator.endRequest fails to execute under certain conditions References: <29812815.1171411805613.JavaMail.jira@brutus> In-Reply-To: <29812815.1171411805613.JavaMail.jira@brutus> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hey Adam, Good catch. Thank you. If you need help merging this into the latest 1.2 branch let me know. The patch does not apply cleanly, but merging everything is not terribly difficult. Scott Adam Winer (JIRA) wrote: > [ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Adam Winer updated ADFFACES-379: > -------------------------------- > > Resolution: Fixed > Status: Resolved (was: Patch Available) > > Checked in. While testing this patch, I noticed some problems with the file upload code, especially > in handling of non-ISO-8859-1 characters. I'm 99% sure these were there before this patch, > and just unnoticed, but fixed them while the code was in front of me. > > >> Configurator.endRequest fails to execute under certain conditions >> ----------------------------------------------------------------- >> >> Key: ADFFACES-379 >> URL: https://issues.apache.org/jira/browse/ADFFACES-379 >> Project: MyFaces ADF-Faces >> Issue Type: Bug >> Components: Portlet >> Environment: JSR-168 >> Reporter: Scott O'Bryan >> Attachments: 13-ADFFACES-379.patch, 13-ADFFACES-379.patch >> >> >> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex. >> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase. >> > >