On 27 July 2013 00:24, James Carman <ja...@carmanconsulting.com> 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.
So long as the docs make very clear that the listener must complete quickly, I don't see why DBCP should have to take additional precautions. Indeed it might be useful for debugging if the listener were synchronous. > 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
