On 09/26/2015 01:11 PM, Gilles wrote: > On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote: >> 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. > > Too bad for me. :-/ > Case resolved, then, by the argument of authority?
I just pointed out that log4j is not a commons component and did not imply anything else. > "Commons" is OK but not another Apache project, by virtue of a > document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to > mention that the "scope" of CM currently goes well beyond "the most > common practical problems not immediately available in the Java > programming language")... > > What's the _technical_ rationale for accepting this dependency and > not accepting that dependency? > >> 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. > > If it is not useful to you, why would you conclude that it is not > useful to others? > > At the cost of repeating myself, once more, the use-case is not > primarily about debugging CM, but sometimes one could need to assess > how a "non-obvious" CM algorithm responds to an application's request. > I've clearly expressed that use-case in a previous message. > > Another example: I have a class that wraps a CM root solver; it is > stuffed with log statements because the message contained in the > "NoBracketingException" was utterly insufficient (and plainly > misleading due the default formatting of numbers) to figure out why > certain calls succeeded and others not. > It's a problem (or a limitation) in the application, but in the > absence of other clues, tracing the solver could help figure out a > workaround. > The alternative to the "logging" approach, would have been to include > a precondition check before calling the solver, that would in effect > duplicate the bracketing check done inside the solver. Given the vast > amount of cases where the code ran smoothly, this is clearly a > sub-optimal solution as compared to turning logging on and rerun the > case that led to a crash. > > What can I say more about the usefulness (for a "low-tech" person > like me) than the intro here: > http://logging.apache.org/log4j/2.x/manual/index.html > ? > >> 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. > > Why are there several log levels? Low-level info can be routed to > "DEBUG" or "TRACE". > As Ole put it quite eloquently, logging is a safety net that we hope > we'll never need, until we do. > > Each layer of an application has its own notion of what is the > appropriate log level. What is "INFO" for some low-level library > will very probably not be so for most applications that use the > library. > Setting levels per package or class takes care of that: it's the > library's *user* who chooses what is useful in the current situation, > not the library's developer. > In the context of that asynchronous collaboration, the role of the > library's developer is to carefully choose what *could* be > interesting, if the need should arise. > > So, can we eventually discuss the _technical_ arguments against > logging inside CM, rather than personal opinion? again, what I want to see is an example what *should* be logged in the case of an algorithm. Take the LevenbergMarquardtOptimizer as an example: * what did you log using System.out.println()? * the algo computes a lot of internal data, which of these is interesting for debugging problems or for general logging? * there are various branches the algo can take, are just some interesting to log, or all of them? the use-cases presented so far were mainly about debugging specific problems, and I am *strongly* against adding logging information just for this purpose as you are clearly facing a dilemma here: you have to log *everything* an algo does as otherwise you might miss the part that creates problems but logging everything is not useful for a standard user of the library so it contradicts the original proposal to include logging Again, CM is not an application where you need to log what it is doing, but a bunch of algorithms and utility methods to perform certain calculations. I fail to see the need to add logging. What could be useful, and we had requests like that in the past, is to observe the state of a certain algorithm and to decide how to proceed in certain cases. That is useful for users. Another useful addition would be to add more aggressive assertions. If one user encounters a problem, he/she could run the application with assertions enabled and spot potential problems e.g. due to wrong input. Logging is a solution for a non existing problem imho. Logging will not avoid the need to debug CM in case of problems imho. Thomas >>>>> 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. > > Has it always been true? > I'm certainly no expert; I only try to stay clear of tools about which > people complain a lot. A few years ago, that was the case of jcl and > jul as compared to slf4j. > > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
