If you can swing moving jdbc-pool as the next gen commons-dbcp - that
would be sweet.
In which case, jdbc-pool would no longer exist and we'd only be left
with dbcp.
Which leaves us with the tomcat 6 vs no access to JDBC4 - but some faqs
can point the user on how to download the needed extra
Filip Hanik - Dev Lists wrote:
> the only downside to my suggestions above is that jdbc-pool doesn't have
> much developer community around it.
> the usage of it has grown, and the bug reports have been very few and no
> major issues are outstanding.
> unless we can build a community around it, w
Hi,
> familiar in what sense? how would jdbc-pool be unfamiliar in terms of
> config?
> I would say the opposite, most users wouldn't even know the difference,
> especially since we don't ship org.apache.commons.dbcp, but we refactor it
> to org.apache.tomcat.dbcp
This refactor has caused queries
On 12/08/2009 11:04 AM, Mark Thomas wrote:
Tim Funk wrote:
[I know I'm missing something .. but] Would it be worth dropping dbcp
from 7 and just use jdbc-pool?
I think dropping dbcp would be bad - it is something that is familiar to
lots of users.
familiar in what sense? how would
Tim Funk wrote:
> [I know I'm missing something .. but] Would it be worth dropping dbcp
> from 7 and just use jdbc-pool?
I think dropping dbcp would be bad - it is something that is familiar to
lots of users.
+1 to including jdbc-pool
Which one to make the default?
My very rough (not really tho
[I know I'm missing something .. but] Would it be worth dropping dbcp
from 7 and just use jdbc-pool?
-Tim
Mark Thomas wrote:
Commons is close to the next DBCP release.
I have been looking at this and there will, unfortunately, still be some
Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It
Commons is close to the next DBCP release.
I have been looking at this and there will, unfortunately, still be some
Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It isn't possible to
work around them without a complete refactoring and/or multiple JARs
and/or use of something like BCEL.
Rather t
