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 abstraction. 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. Mark > > 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
