Yes, moving forward would be great. Foremost on my list is: 0) Generification (POOL-83)
All other items are fine with me but generics is #1. > "pool2." That's fine by me, since removing (deprecated) methods breaks compatibility. Gary - Gary Gregory Senior Software Engineer Seagull Software email: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com -----Original Message----- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Sunday, September 12, 2010 11:14 To: Commons Developers List Subject: [pool] Start work on 2.0? I would like to begin working toward a version 2.0 of [pool]. I would also like to declare the 1.x codebase as officially "bugfix only." If others are OK with this and there is sufficient interest in working toward a pool 2.0, I will cut a 1.x legacy branch and start discussing / coding / applying patches for the following 2.0 features in trunk: 0) Generification (POOL-83) 1) Replace wait/notify with 1.5+ thread management 2) JMX instrumentation and management 3) Remove deprecated methods 4) Instance tracking (holding references to instances under management and tracking events of interest from them - meeting DBCP AbanonedObjectPool requirement) 5) Clean up and extend pool maintenance Obviously, this is just my personal wish-list for [pool] and I am open to any and all other ideas / itches. What I would really like to know at this point is whether or not there is community interest in a modernized version of [pool] containing features like the ones listed above. Ugly as it may be, I think that given the level of reuse of [pool], if we do move forward with 2.0, we will have to change the package name to "pool2." So I guess I am asking for consensus to make that change in trunk as well. Thanks in advance! Phil --------------------------------------------------------------------- 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
