On Tue, 2008-10-21 at 08:09 -0600, Filip Hanik - Dev Lists wrote:
if there are no objections, I'll start integrating this into trunk
tonight or tomorrow,
-1.
Tomcat does not do connection pools. Commons-pool/-dbcp is used instead,
so you should contribute your code to the right project, I
Filip,
On Tue, Oct 21, 2008 at 10:09 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
if there are no objections, I'll start integrating this into trunk tonight or
tomorrow,
I've read the bug in Bugzilla and looked at the code. I understand
why you want a new connection pool
I think there is a solution that would make everyone happy :-) - put this
code and
everything that depends on it in a separate module ( separate == different
release cycle and binary ). I don't know if it should be in a separate svn
tree, probably
would be better.
Then you can cut a release - and
My primary concern is to have the dependency right - the new module can
depend on tomcat,
but tomcat should not have any direct dep. on the new code. I wouldn't mind
if all the existing JDBC
related components would move to the new module as well :-).
Costin is a long time supporter of
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
https://issues.apache.org/jira/browse/POOL-75
2. Remy's comment
On Tue, Oct 21, 2008 at 11:15 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
I hear both of your concerns, and I will withdraw the proposal, thanks for
speaking up
These are all good comments. Is it possible to package up in a way
that core Tomcat does not depend on it, like Costin
On Tue, 2008-10-21 at 09:15 -0600, 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
Oddly enough - I started reading the code today. There are some minor
tweaks without digging too deep into the code:
ProxyConnection.java
This should be CLOSE_VAL.equals(method.getName())
if (CLOSE_VAL==method.getName()) {
PoolProperties
protected String name = Filip Connection
On Tue, Oct 21, 2008 at 5:15 PM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] 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
4. Going with the little piece of code (8classes) elsewhere is a bit moot,
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
Yoav Shapira wrote:
On Tue, Oct 21, 2008 at 11:15 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
I hear both of your concerns, and I will withdraw the proposal, thanks for
speaking up
These are all good comments. Is it possible to package up in a way
that core Tomcat does not
Tim Funk wrote:
Oddly enough - I started reading the code today. There are some minor
tweaks without digging too deep into the code:
ProxyConnection.java
This should be CLOSE_VAL.equals(method.getName())
if (CLOSE_VAL==method.getName()) { .
aren't method names in the constant pool?
Mark Thomas:
Filip Hanik - Dev Lists wrote:
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
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
Markus Schönhaber wrote:
Mark Thomas:
Filip Hanik - Dev Lists wrote:
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
gentlemen,
having run into issues with performance around commons-dbcp as number of
logical cpus increase, no such method exceptions using newer JDKs, I've
made a small code contribution
https://issues.apache.org/bugzilla/show_bug.cgi?id=46038
description and documentation is in the bug, and
16 matches
Mail list logo
