commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hasan Diwan <hasan.di...@gmail.com>
Subject Re: [Math] Utilitzation of SLF4J?
Date Fri, 25 Sep 2015 23:52:26 GMT
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

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


-- 
OpenPGP: https://hasan.d8u.us/gpg.key
Sent from my mobile device
Envoyé de mon portable

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message