commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [logging] logging vs slf4j
Date Sat, 06 Aug 2011 04:26:52 GMT
On Fri, Aug 5, 2011 at 4:07 PM, Gary Gregory <> wrote:
> On Aug 5, 2011, at 16:27, Phil Steitz <> 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 :)


[Grim Reaper, Janitor, Mr Attic etc etc]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message