On 9/26/15 4:56 AM, Thomas Neidhart wrote: > 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.
+1 The other thing I would add is that the one place where it does make sense to dump text is in exception error messages, which is a place where I think we could really improve things. Fortunately, that is fairly easily done. I have seen nothing in this thread to convince me that adding logging in [math] will be net positive for either those of us who maintain the component or for users. If we are not providing clear exception error messages and/or APIs (with complete documentation) so that users can understand what they need to debug their applications, then we should focus on solving those problems. Phil > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
