commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [DBCP] DBCP2 and logging
Date Mon, 29 Jul 2013 14:59:27 GMT
On 27/07/2013 00:24, James Carman wrote:
> Perhaps an event listener for all dbcp events?  Then folks can log it
> themselves.  I would be concerned about performance unless of course the
> events are delivered asynchronously.

My initial reaction was - neat idea lets do it.

However, on further reflection I'm not convinced this helps much in the
DBCP case.

The requirements for logging in DBCP are such that any event listener
would end up looking very much like a logging abstraction and one of the
reasons for using C-L was to to avoid implementing yet another logging

Where I think an event listener approach would work is in POOL. In POOL
there is a very small, very specific logging requirement (the few places
where an exception is swallowed). Currently, this is implemented with
JMX notifications which was the least bad of the options that were
suggested at the time. However, an event listener is significantly
better than JMX. I wish I had thought of that solution before I spent
the time on JMX notifications. Doesn't stop me using the idea though :)

I'll create an JIRA to replace the JMX notifications with a
SwallowedExceptionListener or similar.

Thanks for suggesting this.


> 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