Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.192.169 as permitted sender)
Message-ID: <527BC1B9.1090908@gmail.com>
Date: Thu, 07 Nov 2013 08:37:13 -0800
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [VOTE] Release Apache Commons Pool 2.0 RC4 as 2.0
References: <52783BB4.6080901@apache.org> <527A68C2.3050303@gmail.com>
 <527AB6B7.2020508@gmail.com> <527B5FA1.60704@apache.org>
In-Reply-To: <527B5FA1.60704@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 11/7/13 1:38 AM, Mark Thomas wrote:
> On 06/11/2013 21:37, Phil Steitz wrote:
>> My +1 below stands, but here is something for the RM (Mark) and
>> others to consider.
>>
>> Following the directions on the main site page, I realized that the
>> change in r 1537253 to break the cyclic dependency between .pool2
>> and .pool2.impl made my instructions incorrect.  I did not fully get
>> the implications of this change when it was committed and I failed
>> to make the appropriate change to the site doc.  I can update the
>> site post-release no problem; but I wonder now if we might want to
>> consider moving DefaultPooledObject up to .pool2 so that the simple
>> (now incomplete) approach documented on the main page can work. 
>> Otherwise, you always have to add the wrap implementation, which I
>> bet in the vast majority of cases will end up just being what
>> makeObject did before the change:
>>
>> @Override
>>  public PooledObject<Foo> wrap(Foo foo) {
>>     return new DefaultPooledObject<Foo>(foo);
>>  }
>>
>> I get that DefaultPooledObject is an impl kind of thing; but so
>> actually is BasePooledObjectFactory.
>>
>> Apologies - once again - for not having noticed this when reviewing
>> the commit and RCs.  I can live with it the way it is and as I said
>> the site doc can be fixed post-release, so I am OK moving forward. 
>> Just wanted to do a little gut check before we pour the cement on
>> this setup.
> I think there are good arguments for both positions that are pretty
> evenly matched. Having opted for one arrangement, I don't see a strong
> enough argument to change it.
>
> The o.a.c.pool2 package currently only contains interfaces, abstract
> classes and a utility class. There are no concrete implementations.
> Moving DefaultPooledObject would change that. Equally, I can see how
> moving it would make things simpler but I did deliberately opt to leave
> it in o.a.c.pool2.impl

Good point.  I suppose moving the other way is also possible (Base*
-> impl) but I see downsides to this too.  I get the logic now. 
Once again, sorry for not having raised this when the change was
made.  
> I'm fine with fixing the docs post release.

OK.  I will fix the docs in trunk.  As I said above, my +1 for these
artifacts stands.

Phil
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org