commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Utilitzation of SLF4J?
Date Sat, 26 Sep 2015 19:59:38 GMT
On Sat, 26 Sep 2015 21:07:20 +0200, Luc Maisonobe wrote:
> 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).

Let us not forget that for a library, we would not have to choose
a logger framework, only a logging API.
IIUC both slf4j and Log4j 2 can plug into each other.


Gilles

>
> best regards,
> Luc
>
>>
>> Ralph
>>
>>
>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <luc@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 
>>>>>>>>>> <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.
>>>>
>>>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message