commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
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 <garydgregory@gmail.com> wrote:
> 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

Looking forward to Logging 1.1.2 being released :)

Hen

[Grim Reaper, Janitor, Mr Attic etc etc]

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


Mime
View raw message