commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [logging] logging vs slf4j
Date Fri, 05 Aug 2011 20:26:44 GMT
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.  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.  

> 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 <> 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" <> wrote:
>>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <>
>> wrote:
>>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <>
>> 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:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message