On Fri, Aug 5, 2011 at 4:07 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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
Looking forward to Logging 1.1.2 being released :) Hen [Grim Reaper, Janitor, Mr Attic etc etc] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
