commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DBCP] DBCP2 and logging
Date Sat, 27 Jul 2013 02:01:08 GMT
On Jul 26, 2013, at 19:24, James Carman <james@carmanconsulting.com> 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.

Gary

>  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] http://markmail.org/message/zuufedzkfx62v5eq
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>>
>>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message