Hi all, sorry to join late the conversation but looks like living in a different timezone *is* an issue :(
I am the person "physically" responsable of the pool2 "big refactoring" and I would be very sorry to see all that work dropped or be useless; if you follow the old pool2 discussion in this ML that drove the refactoring, you would maybe agree that I'm not just a crazy guy :) BTW I agree with Gary vision, things would have worked simpler just adding the generics in pool-1.X and releasing as 2.0, then applying changes/merging fixes step by step, releasing "early and often" following the XP best practice. Can I still be helpful here? I would be much more than happy to use the pool2 with generics ASAP, so it's part of my interest too :) Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Mar 22, 2011 at 8:24 PM, Mark Thomas <ma...@apache.org> wrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
