commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Utilitzation of SLF4J?
Date Sat, 26 Sep 2015 16:42:31 GMT
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 
>>>>>> <>
>>>>>> wrote:
>>>>>>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>>>>>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
>>>>>>>> <>
>>>>>>>> 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
>>>>>>>>>>> Hi Ole,
>>>>>>>>>>>> for a start, I think you are asking the wrong
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>> in the
>>>>>>>>>> past in [math] and each time came to the conclusion
>>>>>>>>>> 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:
>>> ?
>>>> 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

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
So I'm +1 for trying to change, for a change.


>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message