Le 26/09/2015 20:59, Ralph Goers a écrit : > I don’t normally participate in Math but I do feel the need to stick my nose > in here. > 1. You are absolutely correct to determine whether you need logging at all > before discussing what to choose. > 2. If you do decide logging is required: > a. Please stay away from java.util.logging. It really would be the best > solution for a framework like math except it is extremely difficult to > redirect efficiently to some other logging framework. The methods used by > SLF4J and Log4j are imperfect to say the least. > b. Log4j 1.x has reached eol. It effectively has not been supported for 5 > years. > c. Log4j 2 has an API that can be redirected to another logging framework > if desired. > d. Commons logging still works but its API is very primitive by todays > standards. That said, it does work.
>From what I have seen, if I ever were to choose a logging framework for any project, I agree log4j 2 is currently the best choice. I was impressed by slf4j a few years ago, but think now the step further is log4j 2 (without any accurate reason, just a rough feeling). best regards, Luc > > Ralph > > >> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <l...@spaceroots.org> wrote: >> >> Le 26/09/2015 18:42, Gilles a écrit : >>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote: >>>> 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 >>> >>> First, you carefully do not reply to any of the concrete arguments >>> given in this thread, second you give a conclusion to an issue not >>> reported in this thread: exceptions and logging do not provide the >>> same service. >>> >>> At least, I'd wish that people sharing their own opinion (it's >>> nothing more since _zero_ technical argument against logging have >>> been put forth) stop taking the collective "users" on their side. >>> As for *actual* users/maintainers, Ole and I have a need, while >>> Thomas and you haven't. Those are all the facts that exist until >>> now. >>> >>> In such a situation, what do we do as a project; maintain the status >>> quo, or try for a change? >>> On numerous occasions over the years, the status quo was enforced; >>> and I don't see that it benefited the project in terms of new >>> contributors. >>> So I'm +1 for trying to change, for a change. >> >> I think one thing has been written in this thread that is worth >> noting and could be an intermediate position. >> >> It seems to me one place where we could get some useful information, >> and provide it to users is for iterative algorithms (both optimizers >> and solvers have already been mentioned, we could add ode integrators >> as well to this). For such algorithms, having some way to monitor how >> the iterations perform seem an improvement. An observer pattern as >> proposed a few days ago for this kind of algorithms would be fine. >> Once again, something simple and that does not attempt to be hyper >> generic but rather taylored to the algorithms (i.e. most probably >> different observer interfaces for different algorithms types). >> >> This intermediate position would provide something to both users >> and developers, and it would not attempt to log everything and >> add a dependency (I am probably the one who opposed to logging on >> the grounds of dependencies). >> >> best regards, >> Luc >> >>> >>> >>> Gilles >>> >>>>> >>>>> 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 >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> <mailto:dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> <mailto:dev-h...@commons.apache.org> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
