tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Tomcat connection pool contribution
Date Tue, 21 Oct 2008 16:20:11 GMT
Mark Thomas wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy and Yoav, I totally understand where you are coming from, and I
>> have thought about it for while before I suggested adding it here
>> 1. commons-dbcp is very stagnant, they are not even accepting
>> performance improvement patches
> That patch hasn't been rejected. It is more a case of no-one has had the
> cycles to review the latest patch. The commons folks were very
> accommodating with
> once I showed up on dev@commons and started to offer to help.
> Reviewing the open commons-pool and commons-dbcp issues has been on my to
> do list for a while but to date, no-one has raised a Tomcat bug or
> complained on the users list so I haven't got around to it yet.
again, we're talking about such a small project, that is considered 
complete, and would not build a new community around it.
>> 2. Remy's comment -"Tomcat does not do connection pools"
>> We sure do, the fact that we ship with one, means we do connection
>> pools. and we are in the job of refactoring commons-dbcp, and now you
>> can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since
>> the java.sql API's are not implemented. a user doesn't care of this is a
>> project from elsewhere, he/she just feels it is a hinder.
> I am pretty sure it will run on a 1.6 JDK - it just has to be compiled on 1.5
it will run until you get a NoSuchMethodException cause it doesn't have 
the method implemented, so that would qualify as not running in a 
production system
>> 3. Yoav's comment - "I don't want to bloat Tomcat with extra stuff"
>> Depends on the definition of bloating, our hacks around commons-dbcp,
>> the size of the library (commons-dbcp-193k, new pool-36k) itself, and
>> the build script
>> we've already bloated our system with crud from commons-dbcp, not
>> working properly here
> Calling commons-dbcp crud is rather harsh. If there are issues, join the
> commons-dev list and offer to help fix them.
I wasn't calling commons-dbcp crud, however, our refactoring of it is a 
hack around class loading issues, so that is what I referred to, it was 
a necessary evil, but doesn't mean its good nor pretty.
>> 4. Going with the little piece of code (8classes) elsewhere is a bit
>> moot, the code is complete, it's not gonna attract a community based on
>> 8classes. And that is why it would be awkward putting it anywhere else,
>> its not like this code is gonna grow and evolve into a large organic
>> project, hence within the ASF, it would be considered dead even before
>> it started.
> As a refactoring of DBCP (as Remy suggested) in Commons I think there would
> be enough a community behind it.
> would probably be more appropriate, but that brings back 
the original point I brought up
this is not something that draws a big crowd, we'd be fighting over what 
source file to maintain :)
> Putting it in extras is another possibility.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message