Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 7105 invoked from network); 24 Nov 2005 00:23:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Nov 2005 00:23:03 -0000 Received: (qmail 67223 invoked by uid 500); 24 Nov 2005 00:23:01 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 67165 invoked by uid 500); 24 Nov 2005 00:23:00 -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 67153 invoked by uid 99); 24 Nov 2005 00:23:00 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Nov 2005 16:23:00 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [210.86.15.58] (HELO mta206-rme.xtra.co.nz) (210.86.15.58) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Nov 2005 16:24:32 -0800 Received: from mta2-rme.xtra.co.nz ([210.86.15.192]) by mta206-rme.xtra.co.nz with ESMTP id <20051124002233.DMQN4228.mta206-rme.xtra.co.nz@mta2-rme.xtra.co.nz> for ; Thu, 24 Nov 2005 13:22:33 +1300 Received: from [10.3.192.52] ([210.54.44.187]) by mta2-rme.xtra.co.nz with ESMTP id <20051124002232.LCXE14324.mta2-rme.xtra.co.nz@[10.3.192.52]> for ; Thu, 24 Nov 2005 13:22:32 +1300 Message-ID: <43850813.6070707@obsidium.com> Date: Thu, 24 Nov 2005 13:23:47 +1300 From: Simon Kitching User-Agent: Thunderbird 1.4 (X11/20050908) MIME-Version: 1.0 To: MyFaces Development Subject: Release method in UIComponentTag (was Reconnecting UIComponentTag instances ...) References: <4383A60B.3020205@obsidium.com> <4383AF61.5000607@obsidium.com> <6dac79b90511231425u3f80a8eah7ea31079853d07fe@mail.gmail.com> In-Reply-To: <6dac79b90511231425u3f80a8eah7ea31079853d07fe@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 I see that originally _id etc were reset in internalRelease, and they were moved to the release method by this commit: ------------------------------------------------------------------------ r166747 | manolito | 2004-04-27 00:01:39 +1200 (Tue, 27 Apr 2004) | 2 lines more reluctant releasing of members for Resin compatibility So it looks like this is a workaround for a Resin bug. I dont quite understand that; I can't see what bug Resin might have that would be fixed by this but wouldn't break many other things. Is "manolito" around to explain further? Regards, Simon Adam Winer wrote: > Sounds like it is a bug, though that's a very quick impression > without serious thought. > > Re: what happens if the number of tags change from one request > to the next: this is why JSF tags inside of c:if are required to have > an explicitly set ID (think this is stated explicitly in the JSF spec). > > This whole mess is why I proposed JspIdConsumer for JSP 2.1, > which lets you do this reconnecting in a robust manner. > > Cheers, > Adam Winer > > On 11/23/05, Travis Reeder wrote: >> Does anyone have any comment on whether this is a bug or not: >> >>> As you can see UIComponentTag.doEndTag calls internalRelease(). But >>> strangely, members _id, _rendered and _binding are cleared only in >>> release(), not internalRelease(). Maybe that's a bug? >>> >