On 09/26/2015 02:33 AM, Gilles wrote: > On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote: >> On 25 September 2015 at 16:47, Gilles <gil...@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 <gil...@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.
log4j is not a commons component btw. I have not seen a single example of a useful logging message that could be added to commons-math, but we are already discussing which framework to use. The examples with println debugging are not valid imho, because how do you know in advance what you will need to log in order to successfully debug some piece of code and such low-level information should not be captured in logs anyway. >>> 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). That is virtually true for all logging frameworks, including log4j, slf4j, commons-logging. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
