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.
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:;> > >
