commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] Utilitzation of SLF4J?
Date Sat, 26 Sep 2015 17:02:12 GMT
On 9/26/15 9:42 AM, Gilles wrote:
> 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 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
>>>>>>>>>>>> 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
>>>>>>>>>>> times 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
>>>>>>>>>> Fortunately, that has changed. [Although sticking
>>>>>>>>>> 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
>>>>>>>> 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.

I am sorry, Gilles, but amidst all of the verbiage, I have not seen
any concrete arguments showing any specific and compelling use case
showing the need for logging.  Somewhere above there is a reference
to not being able to figure things out based on exception messages,
so I mentioned that improving them could help.
> 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.

I guess I am dense, but I still don't understand the need.  Can you
try to give a specific use case that says more than "I don't want to
run a debugger and I need to see what the variables are?" 

> 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.
> Gilles
>>> Thomas
>>>>>>>> My long-standing mentioning of slf4j was only because of
>>>>>>>> "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:

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

View raw message