commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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
>>>>>>> <gilles@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
>>>>>>>>> <gilles@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.

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?" 


Phil
>
> 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
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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message