commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [DBCP] DBCP2 and logging
Date Sat, 27 Jul 2013 02:01:08 GMT
On Jul 26, 2013, at 19:24, James Carman <> wrote:

> Perhaps an event listener for all dbcp events?  Then folks can log it
> themselves.

I would then expect dbcp to deliver a logging implementation, probably
not hooked up by default.


>  I would be concerned about performance unless of course the
> events are delivered asynchronously.
> On Wednesday, July 24, 2013, Phil Steitz wrote:
>> On 7/24/13 12:56 AM, Mark Thomas wrote:
>>> I'm working my way through the open DBCP bugs with a view to getting the
>>> DBCP code (and the POOL code as some changes may be required there) into
>>> a state where it is ready for the first v2 release.
>>> I've quickly reached DBCP-154 that requests that logging is added. This
>>> is not a new request and goes back to DBCP-4 and possibly earlier. From
>>> memory there are a number of open DBCP bugs that require some form of
>>> logging. There are also lots of places where DBCP logs directly to
>>> stdout or stderr.
>>> This quickly brings us to the point of having to decide which logging
>>> framework to use. This is largely the same debate we had for POOL [1]
>>> but with a few key differences:
>>> - there are many more places where logging is required
>>> - there are many more places where logging could be useful
>>> Because of the volume of logging, I don't believe the JMX approach used
>>> for POOL is viable for DBCP.
>>> Therefore, I intend to go ahead and add a dependency on Commons-Logging.
>> First, many thanks for jumping back in!
>> I have two basic questions:
>> 1) Do we absolutely need logging itself or is there some other way
>> we could satisfy the needs here?  IIRC, there are basically two
>> things that "require" logging in DBCP: a) abandoned connections b)
>> exceptions / warnings.  In a), we want users to be able to log the
>> stack trace of the code that opened the connection.  Case b) splits
>> into all kinds of different stuff.  This may be a little smelly, but
>> I wonder if we could not shove what is really needed in normal
>> operations into JMX properties (which would just hold information
>> from recent messages) and support a debug mode where things get
>> spewed as today to System.err or a configured LogWriter.
>> 2) Are there any real reasons that commons-logging will not meet the
>> need?  I have read the other messages on this thread and have not
>> seen a concrete reason, other than "others like slf2j better."  Have
>> we in fact definitively resolved the classloader-related issues that
>> used to make commons-logging a bad choice?
>> If the answer to 1) is we absolutely need logging and 2) comes down
>> to a matter of taste, I am +1 on commons-logging because I agree
>> with the dogfood argument and also do-ocracy ;)
>> Phil
>>> Mark
>>> [1]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:<javascript:;>
>>> For additional commands, e-mail:<javascript:;>
>>> .
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: <javascript:;>
>> For additional commands, e-mail:<javascript:;>

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

View raw message