On 22/03/2011 18:52, Phil Steitz wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
<snip/>
> I don't
>> mind working with a moving target as long as it is moving towards a
>> clear goal. That goal for me is:
>> - Java 5 / generics
>> - fixing inconsistencies / oddities
>> - improved performance on DBCP in multi-core servers.
> +1
>
> Does the first item include replacing the wait/notify stuff with
> j.util.concurrent primitives?
Yes, in combination with the third item.
>> It would certainly make starting dbcp2 a whole lot easier if most of the
>> pool2 re-factoring had not taken place. I think we made a mistake in not
>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>> of the pool2 changes and don't want to throw them away.
>>
>> What do folks think to the following:
>> - move pool trunk to a POOL_FUTURE branch
>> - restore pool trunk to a copy of the POOL_1_X branch
>> - rename pool package to o.a.c.pool2
>> (in reality this would probably be a merge from POOL_FUTURE)
>> - rename dbcp packages to o.a.c.dbcp2
>> - get pool2 and dbcp2 working together
>> - get Tomcat trunk working with dbcp2
>> - go through the POOL_FUTURE changes one at a time:
>> - merging it into pool2 trunk
>> - updating dbcp2 trunk if necessary
>> - testing updated dbcp2 with Tomcat
>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>> can't easily be fixed skip that change and leave it in POOL_FUTURE
> I am fine with above, though I don't think there are any
> incompatible changes yet in the POOL_1_X branch or dbcp trunk, so
> steps 5 and 6 above are no-ops.
Not quite no-ops. There will be some imports to rename but that should
be the limit of it.
> I also don't want to be a stick in
> the mud, but it would be great to close the handful of issues open
> against POOL_1_X and cut a 1.5.5 before the copy so we could avoid
> having to port fixes. I will cut the release if we can agree on the
> fixes. Same holds for DBCP. A little concerted effort could get
> 1.3.1/1.4.1 out before cutting the new branch.
That makes sense to me. It also gives folks a chance to chime in with
their views on the plan.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
|