existing apache committers have traditionally had few problems about being elected committers here so access shouldn't really be a problem.
Noel, forgive my ignorance but are you an existing committer? I'll nominate you to the commons based on Robert's apparent faith in you ;-).
i'd say that there will probably be quite a difference in atmosphere between the two sub-projects. developing in the jakarta commons means putting up with folks here, subscribing to the commons-dev mailing list (which is pretty high volume) but is high visibility. db-commons should be quieter and more focused on database components.
if people think that moving would be a good idea, then it'd probably be a good idea to check first with the existing committers (probably a VOTE would be a good way to handle it). so i suppose that the first step should really be to propose a VOTE to elect noel as a commons committer. i'd prefer it if it came from one of the existing DBCP committers but if no one steps up sometime soonish i'll set something in motion.
I took a crack at fixing DBCP for Struts 1.1 and decided it was in such bad shape that we (Struts) should just drop it. If other people are willing to fix and support it, I'm +1 on moving to db-commons.
Here is my wish list for DBCP in no particular order:
- Delete the org.apache.commons.jocl package because it's no longer used/needed.
- Analyze the o.a.c.dbcp.cpdsadapter and o.a.c.dbcp.jdbc2pool packages/classes and refactor any useful ideas into the main o.a.c.dbcp package.
- We deprecated all the Abandoned* classes and related functionality but it still needs to be removed. It was an absolutely terrible idea to try and recover connections from poorly written client applications. Adding this to DBCP only increased the number of bugs. I do think logging potential connection leaks is appropriate but it's the application's responsibilty to not lose connections.
- All of the Delegating* classes need to be returned to their pure delegate state. Functionality was added that lead to synchronization problems and wasn't in the spirit of a delegate class.
- Standardize the coding conventions to the Sun Java guidelines. Most DBCP code follows it but some classes don't. Also, drop the hideous _var notation for instance variables. In combination these problems make the code uglier, harder to read, and thus harder to maintain.
I would really like to see DBCP be a production quality connection pooling package so I'm really glad some more people are willing to take care of it.
David
- robert
On Monday, June 23, 2003, at 11:03 PM, Noel J. Bergman wrote:
Martin Poeschl [EMAIL PROTECTED] wrote:dbcp is still used by torque and other projects ... i'm also interrested in maintaining the code .. how's about moving the package to db-commons??
Martin, so long as we get commit access, does it really matter which module?
I view location as orthogonal.
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
