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 Fri, 25 Sep 2015 23:47:09 GMT
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?


Gilles

> [1] http://commons.apache.org/releases/versioning.html
> [2] http://commons.apache.org/proper/commons-math/proposal.html
>
> Thomas
>
>
>> If there are now well-formed answers proving that the fear was
>> unfounded, that is also a change.
>>
>> IMO, logging is quite important for any "non-obvious" code.[1]
>> [I'm again stating that, in that respect, CM is not like the other
>> "Commmons" components.]
>>
>> Several times, I've been obliged to create a modified version of CM
>> to introduce "print" statements (poor man's logging!) in order to
>> figure out why my code did not do what it was supposed to.
>> It also makes a code easier to debug while developing or modifying 
>> it
>> (without resorting to poor man's logging, then deleting the "print",
>> then reinstating them, then deleting them again, ad nauseam).
>>
>> Gilles
>>
>> [1] No quality or complexity judgment implied.
>>
>>
>> Phil
>>>
>>>>
>>>>
>>>> Gilles
>>>>
>>>> Thomas
>>>>>
>>>>>
>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ole.ersoy@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>>
>>>>>> We have been discussing various ways to view what's happening
>>>>>> internally
>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>> I know that
>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>> level
>>>>>> dependency, therefore it should minimize the transitive
>>>>>> dependencies that
>>>>>> it introduces.  The Java community has adopted many means of
>>>>>> dealing with
>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>> for
>>>>>> logging.
>>>>>>
>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>> made me a
>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>> switching
>>>>>> their logger out with SLF4J:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>
>>>>>>
>>>>>> The general process I go through when working with many
>>>>>> dependencies that
>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>> this:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>
>>>>>>
>>>>>> With JDK9 individual modules can define their own isolated set 
>>>>>> of
>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>> someone has
>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>> could use
>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> - Ole
>>>>>>


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


Mime
View raw message