commons-dev mailing list archives

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



> 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 <> 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:

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

View raw message