Hi folks, as far as I understand the mail thread (while not being a Commons Math developer)
* logging could be helpful but it could be argued/reasoned that logging is not required for an utility package * there is no perfect logging framework for all use-cases and deployments * Apache Commons strive for minimal dependencies One thing I did in the past is to add a dummy singleton logger implementation which can be replaced by the user of the library * The dummy implementation will do nothing * Adding another level of indirection will not win a software engineering award * Having a singleton could be an issue if multiple parties within the deployed application is using Commons Math * Replacing the dummy logging stub with you logging framework of choice is a bit tedious In other words - it is not beautiful implementation but could be reasonable work-around to make our two camps happy (or both unhappy) Cheers, Siegfried Goeschl > On 27 Sep 2015, at 04:05, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Le 26 sept. 2015 15:19, "Ralph Goers" <ralph.go...@dslextreme.com> a écrit : >> >> Romain, >> >> Choosing JUL for a framework does a HUGE disservice to the users of your > framework. JUL is by far the worst logging framework design of anything you > could choose. It is like the JDK designers purposely chose to use a > mechanism to map their API to another implementation that really doesn’t > work. SLF4J handles this by not bypassing it and using a JUL handler to > map everything into it, and then uses an “interesting” scheme to try to > make that perform well. Log4j tries to use the method documented by JUL but > it has a few problems. >> > > It is contextual, slf4j with its classloader handling is the worse for > other users...all analyzis lead to a really "common" lib shouldnt rely on > any logging API IMHO. > >> Ralph >> >>> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: >>> >>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <l...@spaceroots.org <mailto: > l...@spaceroots.org>> a écrit : >>>> >>>> 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). >>>> >>> >>> And in 2 years foolog4j will be better. JUL is not perfect for sure but >>> ensures: >>> - no dep >>> - always usable >>> - allows to let the user integrate with the lib without having to fork > it >>> to get rid of a logging dep - think to tomee which consumes N commons > deps, >>> if all uses a different logging framework it is worse to configure and >>> highly inconsistent - that is why we chose jul by default >>> >>> That is for the logging framework choice. >>> Now commons shouldnt log much IMO otherwise it would start to loose > commons >>> in sense of shareable component cause of the integration issues it >>> generates in the final application. >>> >>> - Romain >>> >>>> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
