commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [logging] logging vs slf4j
Date Fri, 05 Aug 2011 23:07:26 GMT
On Aug 5, 2011, at 16:27, Phil Steitz <phil.steitz@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.speirs@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" <flamefew@gmail.com> wrote:
>>>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory <garydgregory@gmail.com>
>>> wrote:
>>>>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict <pbenedict@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message