On Aug 5, 2011, at 16:27, Phil Steitz <phil.ste...@gmail.com> wrote: > On 8/5/11 12:53 PM, Henri Yandell wrote: >> HttpComponents would be SFL4j in my structure. They definitely need >> debugging. >> >> Lang or Codec don't. >> >> If I had to generalize, I'd say it's because HttpComponents is not at >> the bottom of its stack. You need to know what the communication is >> between HttpComponents and the API below it (ie) a http connection to >> a server). >> >> Digester and DBCP are two other areas in which logging is very >> attractive (how is it talking to the XML or a DB). >> >> Pool less so imo - what you really want is status information on the >> state of the pool. Ideally we're talking event-based systems and >> querying rather than just simple logging [not that I've looked at Pool >> in eons]. > > I see [pool] and [dbcp] as having similar needs. Could be good JMX > instrumentation can do it all. Needs from the client perspective > are to be able to query the state of the pool and be notified or > provide a log of events of interest. In the case of [pool], most > events of interest involve the factory, so the workaround up to now > has been to add needed capabilities to the factory. > > I don't get why we should abandon [logging] in favor of a non-ASF, > BDFL-esque thingy if [logging] works as a bridge.
+1 Gary > What I am not > sure about for [pool] and [dbcp] is if JMX instrumentation and some > other API improvements might just meet the need without introducing > logging at all. > > I think we are conflating two different topics on this thread - 1) > future of [logging] 2) what commons components should use for > logging. Unless [logging] has terrible flaws that somehow fixed in > the SF thing, we should use it, IMO. > > Phil >> >> It's a set of decisions you have to make - what I'm advocating (with >> 'if you can help it') is to ask yourself "do I need logging?" rather >> than "how can I add logging?". I think a lot is added due to the >> latter approach. >> >> Hen >> >> On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs <bill.spe...@gmail.com> wrote: >>> IMO, saying "Don't do logging in a library" seems like a bad rule. >>> >>> The HTTPComponents client has logging and it has been VERY helpful to be >>> able to turn on debug logging and see what requests and responses are going >>> over the wire. Yes, I could fire up Wireshark and get the same info, but >>> turning on logging is so much easier... I only wish they had this for the >>> HttpCore stuff. >>> >>> Why do you suggest no logging for libraries? >>> >>> Bill- >>> >>> On Aug 5, 2011 2:19 AM, "Henri Yandell" <flame...@gmail.com> wrote: >>>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pbened...@apache.org> >>> wrote: >>>>>> I prefer Apache driven projects when possible. If LOG4J2 takes off, >>>>>> feature requests would be implemented quicker, I hope. >>>>> I like Log4J just fine thank you very much :) >>>>> >>>>> I'm looking forward to 2.0. >>>> That's generally where I am thought-wise. >>>> >>>> A) If you're a generic reusble library; don't do logging if you can help >>> it. >>>> B) If you are an app, use log4j. >>>> C) If you truly need a bridge, use SLF4j. >>>> >>>> Hen >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> >> > > > --------------------------------------------------------------------- > 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
