for sure since it bothers a bunch of people, doing a superb library which is not usable is useless
*Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/7/25 Benedikt Ritter <brit...@apache.org> > 2013/7/24 Romain Manni-Bucau <rmannibu...@gmail.com> > > > Hmm SLF4J as backend? i'd have thought to the opposite but this way is > > weird. > > > > about CL issue it is mainly the fact few containers isolate it correctly > > from the apps (on this point slf4j is better supported) > > > > Is this lack in container implementations really a problem dbcp should be > concerned with? > > > > > > *Romain Manni-Bucau* > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > > *Blog: **http://rmannibucau.wordpress.com/*< > > http://rmannibucau.wordpress.com/> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > > *Github: https://github.com/rmannibucau* > > > > > > > > 2013/7/24 Gary Gregory <garydgreg...@gmail.com> > > > > > 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 > > > > > > > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter >
