While still in Beta, there is also Log4j 2, which let's you optionally use SLF4J as the back-end.
Gary On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz <phil.ste...@gmail.com> 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 > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > . > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
