On 7/24/13 9:36 AM, Romain Manni-Bucau wrote: > 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)
What exactly do you mean by "slf4j is better supported?" The containers isolate it better? Also, for the containers that do not isolate it correctly, what is the marginal impact of adding it as a dependency to DBCP? Do these containers bundle DBCP as well and not isolate it? What I am trying to understand is what practical impact it would have if we added c-l as a DBCP dependency? Phil > > *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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
