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 14:43:19 GMT
On Sat, 26 Sep 2015 13:56:29 +0200, 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 wrote:
>>>>>>>>>> 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
>>>>>>>>>> "more
>>>>>>>>>> viable"?
>>>>>>>>>> btw. the same discussion has been done for other
>>>>>>>>>>> components as
>>>>>>>>>>> well, and the result usually was: do not add
>>>>>>>>>> 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 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
>>>>>>>> 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()?

Primarily, the evolution of the parameters.

>  * the algo computes a lot of internal data, which of these is
> interesting for debugging problems or for general logging?

I gave an example of a real bug; IIRC it was a problem that
could been seen by following some pretty internal data.

What does it matter which data?  It's one developer's choice
until another adds more statements, as necessary.

>  * there are various branches the algo can take, are just some
> interesting to log, or all of them?

Same answer as above.

> 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

See above about the wise developers' assessment of usefulness.
Although you are right in the absolute, I'm sure that you know 
where to put your first logging statements.
Even if all sources of problems are not located by a single log 
they can certainly be surrounded by two log statements.
Then we can zoom in, etc.  Do I really have to tell that?  Come on...

> but logging everything is not useful for a standard user of the 
> library
> so it contradicts the original proposal to include logging

What do you mean by logging everything?
Is this a black or white situation?
As with the rest of the code, we can discuss what is reasonable, and
what is not, with all the spectrum in between left to "those who do
the work".

Not useful to the "standard user"?  So what?  He does not have to use
it.  What a strange objection; does CM target a "standard user"?
Who is a "standard user" and who is not?

> 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.

All programs do that.

> I fail to see the need to add logging.

I think I got that.
Did you get that _I_ had the need?  What do you propose that I do?
Faced with such an unwillingness to consider other's needs, some would
resort to forking the bit of code they use.  I don't think that's good
for anyone.

> 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.

Yes it is, but it is also an orthogonal concern.  As already pointed 
such a facility could be used by users to log the intermediate steps, 
the cost of each user having to do it for himself (as compared to 
a few lines in his application's config file).

And logging would still be a useful auditing tool even for algorithms 
reporting intermediate states to the caller (or to an observer) would 
a major overkill.
Another example has just come to my mind, a bad memory resurrecting 
the unconscious: the dreaded, ill-fated, half-baked, implementation the
BOBYQA algorithm.  Logging statements would be an irreplaceable help to
confidently refactor the code.

Quoting Apache people:
Experience indicates that logging was an important component of the 
development cycle. It offers several advantages. It provides precise 
context about a run of the application. Once inserted into the code, the 
generation of logging output requires no human intervention. Moreover, 
log output can be saved in persistent medium to be studied at a later 
time. In addition to its use in the development cycle, a sufficiently 
rich logging package can also be viewed as an auditing tool.

As I exposed with two concrete examples, this view is valid both
for internal (the library) and external (the application using the
library) debugging.

> 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.

Orthogonal issue. Does not provide a solution to the reported need.

Contrary to the logging question, the assertion question was given a
concrete, technical, answer when asked some time ago.  Look in the

> Logging is a solution for a non existing problem imho.

Negating another user's (me, a.o. most probably) existing problem.

> Logging will not avoid the need to debug CM in case of problems imho.

Side remark, but correct!
We say that logging can help spot some problems.
With the above sentence you try and imply that we claimed it is a
universal solution.
It is not a reasonable technical argument.


> 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:

View raw message