On Jul 26, 2013, at 19:24, James Carman <ja...@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-unsubscr...@commons.apache.org<javascript:;> >>> For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> >>> >>> . >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org <javascript:;> >> For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
