commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Utilitzation of SLF4J?
Date Sat, 26 Sep 2015 00:33:15 GMT
On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
> On 25 September 2015 at 16:47, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>
>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>
>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles 
>>> <gilles@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>>
>>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>>
>>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>>>
>>>>>> Hi Ole,
>>>>>>>
>>>>>>> for a start, I think you are asking the wrong question.
>>>>>>> First of all we need to agree that we want to add some kind of
>>>>>>> logging
>>>>>>> facility to CM.
>>>>>>> If the outcome is positive, there are a handful of 
>>>>>>> alternatives,
>>>>>>> some of
>>>>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>>>>> commons-logging).
>>>>>>>
>>>>>>>
>>>>>> Could someone summarize why those alternatives were deemed "more
>>>>>> viable"?
>>>>>>
>>>>>> btw. the same discussion has been done for other commons
>>>>>>
>>>>>>> components as
>>>>>>> well, and the result usually was: do not add logging
>>>>>>>
>>>>>>>
>>>>>> What was the rationale?
>>>>>>
>>>>>>
>>>>> Look at the archives.  We have discussed this multiple times in 
>>>>> the
>>>>> past in [math] and each time came to the conclusion that Thomas
>>>>> succinctly states above.  What has changed now?
>>>>>
>>>>>
>>>> We also discussed several times to stick with Java 5.
>>>> Fortunately, that has changed. [Although sticking with Java 7 is 
>>>> still
>>>> a bad decision IMHO.]
>>>>
>>>> As for logging, IIRC, the sole argument was "no dependency" 
>>>> because
>>>> (IIRC) of the potential "JAR hell".
>>>>
>>>>
>>> that's not correct. The decision to not include any dependencies 
>>> has
>>> nothing to do with "JAR hell".
>>>
>>
>> Although I can't find it now, I'm pretty sure that I more than once
>> got such an answer.
>>
>> In order to prevent JAR hell, commons components strictly stick to 
>> the
>>> "Versioning guidelines" [1]
>>>
>>
>> I can't see how it relates.
>> But if you mean that no JAR hell can emerge from using a logging 
>> framework,
>> then that's good news.
>>
>> The no-dependency rule is more related to the proposal of the 
>> component,
>>> see [2]
>>>
>>
>> Thanks for the reminder; in that document, we read:
>>
>>   (1) Scope of the Package
>>    [...]
>>    5. Limited dependencies. No external dependencies beyond Commons
>> components and the JDK
>>
>> So we are fine if use "Log4j 2" as kindly offered by Gary.
>>
>> My long-standing mentioning of slf4j was only because of its
>> "weightlessness" (thanks to the no-op implementation of its API).
>> If "Log4j 2" has followed this path, good for everyone.
>>
>> No objection, then?
>
>
> I'm still not clear what log4j 2 adds -- most Apache java projects 
> seem to
> use log4j 1.2, seems to work well. -- H
>

I can only answer about "slf4j" where the "f" stands for facade: it's 
"only"
an API, with bridges to several logging frameworks (log4j, logback, 
etc.).

The separation of concerns (API vs one of several implementations to 
choose from)
allows the top-level application to uniformly configure logging or to 
disable it
completely (if choosing the "no-op" implementation).

Hopefully, this flexibility has been included in "Log4j 2" (TBC by the 
experts).

Regards,
Gilles

>>
>>
>>
>>>>> [...]


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


Mime
View raw message