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
