[Math] Utilitzation of SLF4J?

[Ole Ersoy <ol...@gmail.com>]

Hello,

We have been discussing various ways to view what's happening internally with algorithms, and the topic of including SLF4J has come up.  I know that this was discussed earlier and it was decided that CM is a low level dependency, therefore it should minimize the transitive dependencies that it introduces.  The Java community has adopted many means of dealing with potential logging conflicts, so I'm requesting that we use SLF4J for logging.

I know that JBoss introduced its own logging system, and this made me a bit nervous about this suggestion, so I looked up strategies for switching their logger out with SLF4J:
http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many dependencies that might use commons-logging instead of SLF4J looks something like this:
http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set of dependencies.  At this point the fix should be a permanent.  If someone has has a very intricate scenario that we have not yet seen, they could use (And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole


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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

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 
>>>>> <gi...@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
>>>>>>> <gi...@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()?

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 
perfectly
where to put your first logging statements.
Even if all sources of problems are not located by a single log 
statement,
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 
out,
such a facility could be used by users to log the intermediate steps, 
at
the cost of each user having to do it for himself (as compared to 
change
a few lines in his application's config file).

And logging would still be a useful auditing tool even for algorithms 
where
reporting intermediate states to the caller (or to an observer) would 
be
a major overkill.
Another example has just come to my mind, a bad memory resurrecting 
from
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
archives.

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


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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Sat, 26 Sep 2015 19:07:53 +0200, Luc Maisonobe 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 
>>>>>>>> <gi...@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
>>>>>>>>>> <gi...@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).

Ole's proposal is interesting only if it entails a complete redesign
(again!) of the relevant parts of the library (iteration/evaluation
handling, convergence checker -- see the whole discussion in the
"LevenberMarquardtOptimizer design" thread).
It wouldn't make much sense to just focus on how to implement
ourselves a special-purpose logging framework for each of the
algorithms which you cite.
But it is true that if we agree on this refactoring, my original
use-case (as a "user") would be readily achievable as a side-effect
of controlling the optimizer (the log statements would be located
in the "observer").

Other potential use-cases of logging (Ole gave several examples)
such as tracing convoluted code like "BOBYQAOptimizer" will not
be addressed however.

Gilles

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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

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 <lu...@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 
>>>>>>>>>> <gi...@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
>>>>>>>>>>>> <gi...@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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Sat, 26 Sep 2015 22:09:35 +0200, Luc Maisonobe wrote:
> Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <lu...@spaceroots.org> a écrit 
>> :
>>>
>>> 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).
>>>
>>
>> And in 2 years foolog4j will be better. JUL is not perfect for sure 
>> but
>> ensures:
>> - no dep
>> - always usable
>> - allows to let the user integrate with the lib without having to 
>> fork it
>> to get rid of a logging dep - think to tomee which consumes N 
>> commons deps,
>> if all uses a different logging framework it is worse to configure 
>> and
>> highly inconsistent - that is why we chose jul by default
>>
>> That is for the logging framework choice.
>> Now commons shouldnt log much IMO otherwise it would start to loose 
>> commons
>> in sense of shareable component cause of the integration issues it
>> generates in the final application.
>
> Big +1 to this. For the [math] case (and commons at whole), 
> dependencies
> should be avoided. In fact looking at log4j pom (even the core pom) 
> one
> can notice it depends on several commons components. This makes me 
> think
> more and more that commons components are the lowest possible level,
> just above java itself.
>
> So I think my message above was already out of scope. It may apply to
> some applications, but not to commons.
>
> thanks for reminding me about that, Romain!

No, you are confusing API (required to write log statements in
the source code) and implementation (required to perform actual
logging at runtime)!
Please see:
  http://logging.apache.org/log4j/2.x/runtime-dependencies.html
which states quite clearly
-----
The Log4J API module has no external dependencies.
-----

[Same for slf4j-api.]

Gilles

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

Re: [Math] Utilitzation of SLF4J?

[Dave Brosius <db...@baybroadband.net>]

slf4j-api.jar also has no required dependencies.

On 09/26/2015 06:14 PM, Ralph Goers wrote:
> The Log4j API has no dependencies.  Log4j-core only requires log4j-api.  It has lots of optional features and so has lots of optional dependencies, but none are required.
>
> Ralph
>
>
>> On Sep 26, 2015, at 1:09 PM, Luc Maisonobe <lu...@spaceroots.org> wrote:
>>
>> Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
>>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <lu...@spaceroots.org> a écrit :
>>>> 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).
>>>>
>>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
>>> ensures:
>>> - no dep
>>> - always usable
>>> - allows to let the user integrate with the lib without having to fork it
>>> to get rid of a logging dep - think to tomee which consumes N commons deps,
>>> if all uses a different logging framework it is worse to configure and
>>> highly inconsistent - that is why we chose jul by default
>>>
>>> That is for the logging framework choice.
>>> Now commons shouldnt log much IMO otherwise it would start to loose commons
>>> in sense of shareable component cause of the integration issues it
>>> generates in the final application.
>> Big +1 to this. For the [math] case (and commons at whole), dependencies
>> should be avoided. In fact looking at log4j pom (even the core pom) one
>> can notice it depends on several commons components. This makes me think
>> more and more that commons components are the lowest possible level,
>> just above java itself.
>>
>> So I think my message above was already out of scope. It may apply to
>> some applications, but not to commons.
>>
>> thanks for reminding me about that, Romain!
>>
>> best regards,
>> Luc
>>
>>> - Romain
>>>
>>>> best regards,
>>>> Luc
>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <lu...@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
>>>>>>>>>>>>>>> <gi...@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> 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 <mailto:
>>> dev-unsubscribe@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
>>> 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 <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>


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

Re: [Math] Utilitzation of SLF4J?

[Ralph Goers <ra...@dslextreme.com>]

The Log4j API has no dependencies.  Log4j-core only requires log4j-api.  It has lots of optional features and so has lots of optional dependencies, but none are required.

Ralph


> On Sep 26, 2015, at 1:09 PM, Luc Maisonobe <lu...@spaceroots.org> wrote:
> 
> Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <lu...@spaceroots.org> a écrit :
>>> 
>>> 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).
>>> 
>> 
>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
>> ensures:
>> - no dep
>> - always usable
>> - allows to let the user integrate with the lib without having to fork it
>> to get rid of a logging dep - think to tomee which consumes N commons deps,
>> if all uses a different logging framework it is worse to configure and
>> highly inconsistent - that is why we chose jul by default
>> 
>> That is for the logging framework choice.
>> Now commons shouldnt log much IMO otherwise it would start to loose commons
>> in sense of shareable component cause of the integration issues it
>> generates in the final application.
> 
> Big +1 to this. For the [math] case (and commons at whole), dependencies
> should be avoided. In fact looking at log4j pom (even the core pom) one
> can notice it depends on several commons components. This makes me think
> more and more that commons components are the lowest possible level,
> just above java itself.
> 
> So I think my message above was already out of scope. It may apply to
> some applications, but not to commons.
> 
> thanks for reminding me about that, Romain!
> 
> best regards,
> Luc
> 
>> 
>> - Romain
>> 
>>> best regards,
>>> Luc
>>> 
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <lu...@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
>>>>>>>>>>>>>> <gi...@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
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>> 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 <mailto:
>> dev-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
>> 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 <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>

Re: [Math] Utilitzation of SLF4J?

[Luc Maisonobe <lu...@spaceroots.org>]

Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
> Le 26 sept. 2015 12:07, "Luc Maisonobe" <lu...@spaceroots.org> a écrit :
>>
>> 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).
>>
> 
> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> ensures:
> - no dep
> - always usable
> - allows to let the user integrate with the lib without having to fork it
> to get rid of a logging dep - think to tomee which consumes N commons deps,
> if all uses a different logging framework it is worse to configure and
> highly inconsistent - that is why we chose jul by default
> 
> That is for the logging framework choice.
> Now commons shouldnt log much IMO otherwise it would start to loose commons
> in sense of shareable component cause of the integration issues it
> generates in the final application.

Big +1 to this. For the [math] case (and commons at whole), dependencies
should be avoided. In fact looking at log4j pom (even the core pom) one
can notice it depends on several commons components. This makes me think
more and more that commons components are the lowest possible level,
just above java itself.

So I think my message above was already out of scope. It may apply to
some applications, but not to commons.

thanks for reminding me about that, Romain!

best regards,
Luc

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

Re: [Math] Utilitzation of SLF4J?

[Gary Gregory <ga...@gmail.com>]

On Mon, Sep 28, 2015 at 10:29 AM, Siegfried Goeschl <
siegfried.goeschl@it20one.com> wrote:

> Hi folks,
>
> as far as I understand the mail thread (while not being a Commons Math
> developer)
>
> * logging could be helpful but it could be argued/reasoned that logging is
> not required for an utility package
> * there is no perfect logging framework for all use-cases and deployments
> * Apache Commons strive for minimal dependencies
>

That's not a good requirement IMO or it is not well stated, not sure. The
Log4j 2 API and Commons Logging API are both a single jar. Both need a
backing implementation.


>
> One thing I did in the past is to add a dummy singleton logger
> implementation which can be replaced by the user of the library
>

So may projects do this, and it's lame; the extra layer invariably is
either not that good and affects the quality of the logging, or grows to
imitate another logging API.

To make matters worse, it's another thing to configure and provide custom
code with to bridge to your logging framework of choice, unless the project
provides an implementation for your logging API of choice.

IOW, pick a logging API (except JUL).

Whether or not a component should log is another matter! ;-)

Gary


>
> * The dummy implementation will do nothing
> * Adding another level of indirection will not win a software engineering
> award
> * Having a singleton could be an issue if multiple parties within the
> deployed application is using Commons Math
> * Replacing the dummy logging stub with you logging framework of choice is
> a bit tedious
>
> In other words - it is not beautiful implementation but could be
> reasonable work-around to make our two camps happy (or both unhappy)
>
> Cheers,
>
> Siegfried Goeschl
>
>
> > On 27 Sep 2015, at 04:05, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Le 26 sept. 2015 15:19, "Ralph Goers" <ra...@dslextreme.com> a
> écrit :
> >>
> >> Romain,
> >>
> >> Choosing JUL for a framework does a HUGE disservice to the users of your
> > framework. JUL is by far the worst logging framework design of anything
> you
> > could choose. It is like the JDK designers purposely chose to use a
> > mechanism to map their API to another implementation that really doesn’t
> > work.  SLF4J handles this by not bypassing it and using a JUL handler to
> > map everything into it, and then uses an “interesting” scheme to try to
> > make that perform well. Log4j tries to use the method documented by JUL
> but
> > it has a few problems.
> >>
> >
> > It is contextual, slf4j with its classloader handling is the worse for
> > other users...all analyzis lead to a really "common" lib shouldnt rely on
> > any logging API IMHO.
> >
> >> Ralph
> >>
> >>> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >>>
> >>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <luc@spaceroots.org <mailto:
> > luc@spaceroots.org>> a écrit :
> >>>>
> >>>> 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).
> >>>>
> >>>
> >>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> >>> ensures:
> >>> - no dep
> >>> - always usable
> >>> - allows to let the user integrate with the lib without having to fork
> > it
> >>> to get rid of a logging dep - think to tomee which consumes N commons
> > deps,
> >>> if all uses a different logging framework it is worse to configure and
> >>> highly inconsistent - that is why we chose jul by default
> >>>
> >>> That is for the logging framework choice.
> >>> Now commons shouldnt log much IMO otherwise it would start to loose
> > commons
> >>> in sense of shareable component cause of the integration issues it
> >>> generates in the final application.
> >>>
> >>> - Romain
> >>>
> >>>> best regards,
> >>>> Luc
> >>>>
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>
> >>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <lu...@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
> >>>>>>>>>>>>>>> <gi...@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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>> 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 <mailto:
> >>> dev-unsubscribe@commons.apache.org>
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> <mailto:
> >>> 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
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Utilitzation of SLF4J?

[Siegfried Goeschl <si...@it20one.com>]

Hi folks,

as far as I understand the mail thread (while not being a Commons Math developer)

* logging could be helpful but it could be argued/reasoned that logging is not required for an utility package 
* there is no perfect logging framework for all use-cases and deployments
* Apache Commons strive for minimal dependencies

One thing I did in the past is to add a dummy singleton logger implementation which can be replaced by the user of the library 

* The dummy implementation will do nothing
* Adding another level of indirection will not win a software engineering award
* Having a singleton could be an issue if multiple parties within the deployed application is using Commons Math
* Replacing the dummy logging stub with you logging framework of choice is a bit tedious 

In other words - it is not beautiful implementation but could be reasonable work-around to make our two camps happy (or both unhappy)

Cheers,

Siegfried Goeschl


> On 27 Sep 2015, at 04:05, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 
> Le 26 sept. 2015 15:19, "Ralph Goers" <ra...@dslextreme.com> a écrit :
>> 
>> Romain,
>> 
>> Choosing JUL for a framework does a HUGE disservice to the users of your
> framework. JUL is by far the worst logging framework design of anything you
> could choose. It is like the JDK designers purposely chose to use a
> mechanism to map their API to another implementation that really doesn’t
> work.  SLF4J handles this by not bypassing it and using a JUL handler to
> map everything into it, and then uses an “interesting” scheme to try to
> make that perform well. Log4j tries to use the method documented by JUL but
> it has a few problems.
>> 
> 
> It is contextual, slf4j with its classloader handling is the worse for
> other users...all analyzis lead to a really "common" lib shouldnt rely on
> any logging API IMHO.
> 
>> Ralph
>> 
>>> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>> 
>>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <luc@spaceroots.org <mailto:
> luc@spaceroots.org>> a écrit :
>>>> 
>>>> 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).
>>>> 
>>> 
>>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
>>> ensures:
>>> - no dep
>>> - always usable
>>> - allows to let the user integrate with the lib without having to fork
> it
>>> to get rid of a logging dep - think to tomee which consumes N commons
> deps,
>>> if all uses a different logging framework it is worse to configure and
>>> highly inconsistent - that is why we chose jul by default
>>> 
>>> That is for the logging framework choice.
>>> Now commons shouldnt log much IMO otherwise it would start to loose
> commons
>>> in sense of shareable component cause of the integration issues it
>>> generates in the final application.
>>> 
>>> - Romain
>>> 
>>>> best regards,
>>>> Luc
>>>> 
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> 
>>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <lu...@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
>>>>>>>>>>>>>>> <gi...@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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>>>> 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 <mailto:
>>> dev-unsubscribe@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
>>> 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

Re: [Math] Utilitzation of SLF4J?

[Romain Manni-Bucau <rm...@gmail.com>]

Le 26 sept. 2015 15:19, "Ralph Goers" <ra...@dslextreme.com> a écrit :
>
> Romain,
>
> Choosing JUL for a framework does a HUGE disservice to the users of your
framework. JUL is by far the worst logging framework design of anything you
could choose. It is like the JDK designers purposely chose to use a
mechanism to map their API to another implementation that really doesn’t
work.  SLF4J handles this by not bypassing it and using a JUL handler to
map everything into it, and then uses an “interesting” scheme to try to
make that perform well. Log4j tries to use the method documented by JUL but
it has a few problems.
>

It is contextual, slf4j with its classloader handling is the worse for
other users...all analyzis lead to a really "common" lib shouldnt rely on
any logging API IMHO.

> Ralph
>
> > On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> >
> > Le 26 sept. 2015 12:07, "Luc Maisonobe" <luc@spaceroots.org <mailto:
luc@spaceroots.org>> a écrit :
> >>
> >> 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).
> >>
> >
> > And in 2 years foolog4j will be better. JUL is not perfect for sure but
> > ensures:
> > - no dep
> > - always usable
> > - allows to let the user integrate with the lib without having to fork
it
> > to get rid of a logging dep - think to tomee which consumes N commons
deps,
> > if all uses a different logging framework it is worse to configure and
> > highly inconsistent - that is why we chose jul by default
> >
> > That is for the logging framework choice.
> > Now commons shouldnt log much IMO otherwise it would start to loose
commons
> > in sense of shareable component cause of the integration issues it
> > generates in the final application.
> >
> > - Romain
> >
> >> best regards,
> >> Luc
> >>
> >>>
> >>> Ralph
> >>>
> >>>
> >>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <lu...@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
> >>>>>>>>>>>>> <gi...@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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> > ---------------------------------------------------------------------
> >>>>>>> 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 <mailto:
> > dev-unsubscribe@commons.apache.org>
> >>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> > dev-help@commons.apache.org>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
>

Re: [Math] Utilitzation of SLF4J?

[Ralph Goers <ra...@dslextreme.com>]

Romain, 

Choosing JUL for a framework does a HUGE disservice to the users of your framework. JUL is by far the worst logging framework design of anything you could choose. It is like the JDK designers purposely chose to use a mechanism to map their API to another implementation that really doesn’t work.  SLF4J handles this by not bypassing it and using a JUL handler to map everything into it, and then uses an “interesting” scheme to try to make that perform well. Log4j tries to use the method documented by JUL but it has a few problems.

Ralph

> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 
> Le 26 sept. 2015 12:07, "Luc Maisonobe" <luc@spaceroots.org <ma...@spaceroots.org>> a écrit :
>> 
>> 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).
>> 
> 
> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> ensures:
> - no dep
> - always usable
> - allows to let the user integrate with the lib without having to fork it
> to get rid of a logging dep - think to tomee which consumes N commons deps,
> if all uses a different logging framework it is worse to configure and
> highly inconsistent - that is why we chose jul by default
> 
> That is for the logging framework choice.
> Now commons shouldnt log much IMO otherwise it would start to loose commons
> in sense of shareable component cause of the integration issues it
> generates in the final application.
> 
> - Romain
> 
>> best regards,
>> Luc
>> 
>>> 
>>> Ralph
>>> 
>>> 
>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <lu...@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
>>>>>>>>>>>>> <gi...@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
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
> ---------------------------------------------------------------------
>>>>>>> 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 <mailto:
> dev-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> dev-help@commons.apache.org>
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

[Romain Manni-Bucau <rm...@gmail.com>]

Le 26 sept. 2015 12:07, "Luc Maisonobe" <lu...@spaceroots.org> a écrit :
>
> 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).
>

And in 2 years foolog4j will be better. JUL is not perfect for sure but
ensures:
- no dep
- always usable
- allows to let the user integrate with the lib without having to fork it
to get rid of a logging dep - think to tomee which consumes N commons deps,
if all uses a different logging framework it is worse to configure and
highly inconsistent - that is why we chose jul by default

That is for the logging framework choice.
Now commons shouldnt log much IMO otherwise it would start to loose commons
in sense of shareable component cause of the integration issues it
generates in the final application.

- Romain

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

Re: [Math] Utilitzation of SLF4J?

[Luc Maisonobe <lu...@spaceroots.org>]

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

best regards,
Luc

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


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

Re: [Math] Utilitzation of SLF4J?

[Ralph Goers <ra...@dslextreme.com>]

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.

Ralph


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

Re: [Math] Utilitzation of SLF4J?

[Luc Maisonobe <lu...@spaceroots.org>]

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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Sat, 26 Sep 2015 10:02:12 -0700, Phil Steitz wrote:
> 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
>>>>>>>> <gi...@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
>>>>>>>>>> <gi...@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

There were at least 3 specific examples of real cases (a bug in CM,
a way to help debug an application using CM, a tool to help refactor
an overly convoluted code in CM).

Then Ole also gave quite a few others in a very constructive post
that took the time to reply point-by-point to your objections.
Faced with some reluctance (which is by itself acceptable), we try to
make our points more specific by expanding that which we otherwise
think is obvious; but that is called "verbiage".

I have not seen any technical argument against logging.
See below for non-technical opinions that are at 180 degrees of
your views on the subject.
If you could accept that in this area also, it may be possible
that no hard rules are needed.

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

That was part of the second example, saying that even the most
excruciatingly precise error message would not have helped.
Context is what mattered more.

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

This is actually one of the points!  Aren't we in good company
with this quote (found at our fellow Apache Log4J people's site):
-----
As Brian W. Kernighan and Rob Pike put it in their truly excellent book 
"The Practice of Programming":
As personal choice, we tend not to use debuggers beyond getting a stack 
trace or the value of a variable or two. One reason is that it is easy 
to get lost in details of complicated data structures and control flow; 
we find stepping through a program less productive than thinking harder 
and adding output statements and self-checking code at critical places. 
Clicking over statements takes longer than scanning the output of 
judiciously-placed displays. It takes less time to decide where to put 
print statements than to single-step to the critical section of code, 
even assuming we know where that is. More important, debugging 
statements stay with the program; debugging sessions are transient.
-----

The following is also a nice reading for another opinion on logging:
   
http://vasir.net/blog/development/how-logging-made-me-a-better-developer

And... I don't want to run a debugger. :-!

Gilles

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


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

Re: [Math] Utilitzation of SLF4J?

[Phil Steitz <ph...@gmail.com>]

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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

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


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

Re: [Math] Utilitzation of SLF4J?

[Phil Steitz <ph...@gmail.com>]

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

Re: [Math] Utilitzation of SLF4J?

[Thomas Neidhart <th...@gmail.com>]

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

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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

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 
>>> <gi...@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 
>>>>> <gi...@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?
"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?

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

Re: [Math] Utilitzation of SLF4J?

[Thomas Neidhart <th...@gmail.com>]

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

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.

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.

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

Thomas

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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
> On 25 September 2015 at 16:47, Gilles <gi...@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 
>>> <gi...@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.
>>
>> 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).

Hopefully, this flexibility has been included in "Log4j 2" (TBC by the 
experts).

Regards,
Gilles

>>
>>
>>
>>>>> [...]


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

Re: [Math] Utilitzation of SLF4J?

[Hasan Diwan <ha...@gmail.com>]

On 25 September 2015 at 16:47, Gilles <gi...@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 <gi...@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.
>
> 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

>
>
>
> Gilles
>
>
> [1] http://commons.apache.org/releases/versioning.html
>> [2] http://commons.apache.org/proper/commons-math/proposal.html
>>
>> Thomas
>>
>>
>> If there are now well-formed answers proving that the fear was
>>> unfounded, that is also a change.
>>>
>>> IMO, logging is quite important for any "non-obvious" code.[1]
>>> [I'm again stating that, in that respect, CM is not like the other
>>> "Commmons" components.]
>>>
>>> Several times, I've been obliged to create a modified version of CM
>>> to introduce "print" statements (poor man's logging!) in order to
>>> figure out why my code did not do what it was supposed to.
>>> It also makes a code easier to debug while developing or modifying it
>>> (without resorting to poor man's logging, then deleting the "print",
>>> then reinstating them, then deleting them again, ad nauseam).
>>>
>>> Gilles
>>>
>>> [1] No quality or complexity judgment implied.
>>>
>>>
>>> Phil
>>>
>>>>
>>>>
>>>>>
>>>>> Gilles
>>>>>
>>>>> Thomas
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>>
>>>>>>> We have been discussing various ways to view what's happening
>>>>>>> internally
>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>> I know that
>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>> level
>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>> dependencies that
>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>> dealing with
>>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>>> for
>>>>>>> logging.
>>>>>>>
>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>> made me a
>>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>>> switching
>>>>>>> their logger out with SLF4J:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>
>>>>>>>
>>>>>>> The general process I go through when working with many
>>>>>>> dependencies that
>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>> this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>
>>>>>>>
>>>>>>> With JDK9 individual modules can define their own isolated set of
>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>> someone has
>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>> could use
>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> - Ole
>>>>>>>
>>>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
OpenPGP: https://hasan.d8u.us/gpg.key
Sent from my mobile device
Envoyé de mon portable

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Sat, 26 Sep 2015 02:00:13 +0200, Bernd Eckenfels wrote:
> For such a simple case like logging in a (math) library you can also 
> use
> the JDK jul logging.

This may make you change your mind:
   
http://stackoverflow.com/questions/11359187/why-not-use-java-util-logging

> However I really do not see a need for it

Examples were given in this thread.

> (and I
> think it can negatively impact the user experience of a lib if it 
> does
> logging even when it has no environmental interactions)

Could you elaborate on "negatively impact"?  Thanks.

>
> Am Sat, 26 Sep
> 2015 01:47:09 +0200 schrieb Gilles <gi...@harfang.homelinux.org>:
>
>> 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.
>>
>> 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?
>
> Uh, be carefull with the trigger of that gun you point at somenes
> chest :)

Sure. :-D

Regards,
Gilles


> Gruss
> Bernd
>


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

Re: [Math] Utilitzation of SLF4J?

[Bernd Eckenfels <ec...@zusammenkunft.net>]

For such a simple case like logging in a (math) library you can also use
the JDK jul logging.

However I really do not see a need for it (and I
think it can negatively impact the user experience of a lib if it does
logging even when it has no environmental interactions)


Am Sat, 26 Sep
2015 01:47:09 +0200 schrieb Gilles <gi...@harfang.homelinux.org>:

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

Uh, be carefull with the trigger of that gun you point at somenes
chest :)

Gruss
Bernd

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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
> On Fri, Sep 25, 2015 at 5:09 PM, Gilles 
> <gi...@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.

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?


Gilles

> [1] http://commons.apache.org/releases/versioning.html
> [2] http://commons.apache.org/proper/commons-math/proposal.html
>
> Thomas
>
>
>> If there are now well-formed answers proving that the fear was
>> unfounded, that is also a change.
>>
>> IMO, logging is quite important for any "non-obvious" code.[1]
>> [I'm again stating that, in that respect, CM is not like the other
>> "Commmons" components.]
>>
>> Several times, I've been obliged to create a modified version of CM
>> to introduce "print" statements (poor man's logging!) in order to
>> figure out why my code did not do what it was supposed to.
>> It also makes a code easier to debug while developing or modifying 
>> it
>> (without resorting to poor man's logging, then deleting the "print",
>> then reinstating them, then deleting them again, ad nauseam).
>>
>> Gilles
>>
>> [1] No quality or complexity judgment implied.
>>
>>
>> Phil
>>>
>>>>
>>>>
>>>> Gilles
>>>>
>>>> Thomas
>>>>>
>>>>>
>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>>
>>>>>> We have been discussing various ways to view what's happening
>>>>>> internally
>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>> I know that
>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>> level
>>>>>> dependency, therefore it should minimize the transitive
>>>>>> dependencies that
>>>>>> it introduces.  The Java community has adopted many means of
>>>>>> dealing with
>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>> for
>>>>>> logging.
>>>>>>
>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>> made me a
>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>> switching
>>>>>> their logger out with SLF4J:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>
>>>>>>
>>>>>> The general process I go through when working with many
>>>>>> dependencies that
>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>> this:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>
>>>>>>
>>>>>> With JDK9 individual modules can define their own isolated set 
>>>>>> of
>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>> someone has
>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>> could use
>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> - Ole
>>>>>>


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

Re: [Math] Utilitzation of SLF4J?

[Thomas Neidhart <th...@gmail.com>]

On Fri, Sep 25, 2015 at 5:09 PM, Gilles <gi...@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".

In order to prevent JAR hell, commons components strictly stick to the
"Versioning guidelines" [1]

The no-dependency rule is more related to the proposal of the component,
see [2]

[1] http://commons.apache.org/releases/versioning.html
[2] http://commons.apache.org/proper/commons-math/proposal.html

Thomas


> If there are now well-formed answers proving that the fear was
> unfounded, that is also a change.
>
> IMO, logging is quite important for any "non-obvious" code.[1]
> [I'm again stating that, in that respect, CM is not like the other
> "Commmons" components.]
>
> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.
> It also makes a code easier to debug while developing or modifying it
> (without resorting to poor man's logging, then deleting the "print",
> then reinstating them, then deleting them again, ad nauseam).
>
> Gilles
>
> [1] No quality or complexity judgment implied.
>
>
> Phil
>>
>>>
>>>
>>> Gilles
>>>
>>> Thomas
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>> wrote:
>>>>
>>>> Hello,
>>>>>
>>>>> We have been discussing various ways to view what's happening
>>>>> internally
>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>> I know that
>>>>> this was discussed earlier and it was decided that CM is a low
>>>>> level
>>>>> dependency, therefore it should minimize the transitive
>>>>> dependencies that
>>>>> it introduces.  The Java community has adopted many means of
>>>>> dealing with
>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>> for
>>>>> logging.
>>>>>
>>>>> I know that JBoss introduced its own logging system, and this
>>>>> made me a
>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>> switching
>>>>> their logger out with SLF4J:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>
>>>>>
>>>>> The general process I go through when working with many
>>>>> dependencies that
>>>>> might use commons-logging instead of SLF4J looks something like
>>>>> this:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>
>>>>>
>>>>> With JDK9 individual modules can define their own isolated set of
>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>> someone has
>>>>> has a very intricate scenario that we have not yet seen, they
>>>>> could use
>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers,
>>>>> - Ole
>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Math] Utilitzation of SLF4J?

[Ole Ersoy <ol...@gmail.com>]

On 09/25/2015 03:06 PM, Phil Steitz wrote:
> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>> I disagree. Good tests, API contracts, exception management and
>>> documentation can and should eliminate the need for cluttering
>>> low-level library code with debug logging.
>> Logging could be viewed as clutter.  Constructed the right way,
>> the logging statements could also be viewed as comments.
>>
>> I agree that good tests, API contracts, and in general keeping the
>> design as minimalistic and simple as possible should be the first
>> criteria to review before introducing logging.  When the code is
>> trivial I leave logging out, unless I need to put in a few
>> statements in order to track collaboration between components in
>> an algorithm.
>> Other times the method is as simple as it gets and I have to have
>> logging.  For example take the LevenbergMarquardtOptimizer
>> optimize() method.  It's atomic in the sense that what's in the
>> method belongs in the method.  There are several loops within the
>> main loop, etc. and tracking what's going, even with a observer
>> being notified on each increment, would be far from elegant.
> Why, exactly do you need to "track what is going on?"
I hope that I don't.  Most of the time code we write, especially the CM code, is rock solid.  When implementing complex algorithms we break it down to simple building blocks, reason about it, break it down some more, unit test it, and it looks fantastic.  Then we hit a snag, and start putting in println statements.  Then we delete these after the fix, cut up 5 chickens, and pray.

If an issue occurs, then there is a low probability that it is a CM component.  The traces can help prove that it is not the CM component.

If the code is now rock solid, then the log statements bother no one.  We put the code back in production, trace initially to make sure everything looks healthy, and then turn off logging.  On the flip side if we notice that something else seems off, we're back to putting in the println statements again.

Watching traces of CM components in production is an additional insurance policy for guaranteeing quality.

Also if there is an issue, and someone needs to understand it fast, the best way is to watch data flow through the system.  For new contributors, this could be a good way to get up to speed on an algorithm.


>    If you need
> to do that as a user of the code, some kind of listener or API to
> give you the information that you need is appropriate.
I agree, but as I showed with the LevenbergMarquardtOptimizer attempting inject code into the optimize() method is a non trivial exercise.  Components should have a simple way to examine discrete steps that are being performed.

>    Dumping text
> to an external resource to "solve" this usually indicates smelliness
> somewhere - either in the library API or the client code.
Or it is a precaution to ensure that no one forgot to flush.

>
>> For example perhaps we want to see what's going on with the
>> parameters in this small (5% of the method size) section of code:
> What parameters and where did they come from?  If from the client,
> the client can validate them.  If the library needs to validate or
> confirm suitability, then it should do that in code or via tests.
>>                  // compute the scaled predicted reduction
>>                  // and the scaled directional derivative
>>                  for (int j = 0; j < solvedCols; ++j) {
>>                      int pj = permutation[j];
>>                      double dirJ = lmDir[pj];
>>                      work1[j] = 0;
>>                      for (int i = 0; i <= j; ++i) {
>>                          work1[i] += weightedJacobian[i][pj] * dirJ;
>>                      }
>>                  }
>>
>> If there is something wrong with this in production, the shortest
>> path to figuring that out is reviewing a trace.  The longer path
>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>> the data.
>>
>> If we wanted to observe this section of code the observer would be
>> looking at sub loops of of the optimize method.  So that's doable,
>> but it creates an interface design for the observer that's
>> cluttered with events corresponding to various low level algorithm
>> details.
>>
>>
>>>> Several times, I've been obliged to create a modified version of CM
>>>> to introduce "print" statements (poor man's logging!) in order to
>>>> figure out why my code did not do what it was supposed to.
>> It's pretty tragic that anyone of us should have to do this.  It's
>> also wasteful, because if Gilles has to do this, then there's a
>> good chance that others have to do it to.  The reason Tomcat logs
>> at various levels is so that we can see what's going on in
>> production and track down bugs.
> No.  Have a look at the Tomcat logging code.  It is mostly
> initialization, shutdown and exceptions or warnings.

I agree, but I would argue that these should be far simpler to reason about than the life cycle of some of the CM algorithms.

>    This is
> necessary because tomcat is a container - there is no client
> application to catch exceptions or get API results back.
The use case is the same.  If there is a production problem, it will show up in the logs.  This is what Gilles and I are asking for.  The ability to help diagnose component performance by reviewing a trace.  If the component is rock solid, then the additional tracing is free.

Part of this reminds me of a hesitation I had with use Markdown syntax for tables.  It's pretty tedious to line up all the pipes, etc. to make the tables look pretty.  Then I downloaded atom and a markdown plugin, and it automatically did it for me.

It should be pretty easy to hide logging statements in code via tooling. I just searched, and it does not look like it exists yet, but at least others are thinking about it:
http://stackoverflow.com/questions/10705814/how-to-write-eclipse-plugin-to-hide-logger-statements


>    The analog
> for the kind of instrumentation you are proposing inside [math]
> would be like tomcat larding itself up with debug logging throughout
> the request processing lifecycle, which it does not do.
I agree, but the request API publishes a great deal of detail about each request.  Also Tomcat is in production all over the place.  It goes through a lot of hammering.  Math components get far less exposure....probably in the order of 1/100,000.,,I think would be a conservative estimate.


>     It is a
> bad analogy in any case, because Tomcat is a container, which is 2
> big steps up the processing chain from a low-level library.
That's fair.  The CM developers are all very talented though.  I don't think Gilles is going to get all sloppy joe with his logging. He cares a great deal about the code quality, just like everyone else.  I think if we OK logging, then initially Gilles will probably be the only one using it, because he strongly feels he needs it. The rest of us seem fairly content with the state of the components, so I'm guessing the components will stay the way they are for a while.  If there is nothing wrong, then there is no need to introduce tracing.

When I perform the LevenbergMarquardtOptimizer I'm about to embark on, I'm going to introduce tracing just to learn more about the algorithms dynamics.  It would be a shame to have to delete the tracing when the refactoring is complete.

Introducing tracing is going to give future maintainers and contributors a great on ramp.

Cheers,
- Ole



>
> Phil
>
>> Lets become one with the logging and make it into something that
>> strengthens both code integrity and comprehensibility.  Everyone
>> take take out your Feng Shui mat and do some deep breathing right
>> now.
>>
>>> Here again, tests, good design, code inspection are the way to go in
>>> low-level components.  I have also spent a lot of time researching
>>> bugs in [math], other Commons components and other complex systems.
>>> My experience is a little different: excessive logging / debug code
>>> for code that contains it often just tends to get in the way,
>> It's a very good point.  Sometimes we come across logging
>> statements that are just noise.  Given how rigorous we are about
>> reviewing everything though, I think a win win would be to limit
>> the noise during code review, and pledge not to "Call our mom" in
>> the middle of the code, etc.
>>
>>> especially after it has rotted a bit.  Rather than adding more code
>>> to maintain so that you can have less conceptual control over the
>>> functional code, it is better, IMNSHO, to focus on making the
>>> functional code as simple as possible with clean well-documented,
>>> test-validated API contracts.
>> Totally agree.  I think this should be the first priority, and
>> that logging should be used when there are no simple clean
>> alternatives.
>>
>>>> It also makes a code easier to debug while developing or
>>>> modifying it
>>>> (without resorting to poor man's logging, then deleting the
>>>> "print",
>>>> then reinstating them, then deleting them again, ad nauseam).
>> Pretty sure we have all been here.
>>
>> Cheers,
>> - Ole
>>
>>
>>>> Gilles
>>>>
>>>> [1] No quality or complexity judgment implied.
>>>>
>>>>> Phil
>>>>>> Gilles
>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> We have been discussing various ways to view what's happening
>>>>>>>> internally
>>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>>> I know that
>>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>>> level
>>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>>> dependencies that
>>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>>> dealing with
>>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>>> SLF4J
>>>>>>>> for
>>>>>>>> logging.
>>>>>>>>
>>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>>> made me a
>>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>>> for
>>>>>>>> switching
>>>>>>>> their logger out with SLF4J:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The general process I go through when working with many
>>>>>>>> dependencies that
>>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>>> this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>>> set of
>>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>>> someone has
>>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>>> could use
>>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Ole
>>>> ---------------------------------------------------------------------
>>>>
>>>> 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

Re: [Math] Utilitzation of SLF4J?

[Hasan Diwan <ha...@gmail.com>]

Oughtn't there be an option to have logging for developers? If you'd like
to use it, feel free; if not, don't. Including log4j (or slf or
commons-logging, so on) doesn't add too much weight to the jar -- one file,
a small properties file, and 4-lines in the pom file. If there is interest,
I can submit a patch adding log4j and log4j.properties to JIRA. Let me
know? -- H

On 25 September 2015 at 16:26, Gilles <gi...@harfang.homelinux.org> wrote:

> On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote:
>
> I say something like: "I had to fork some CM class to insert
> log statements."
> You say something like: "No, you don't; write test or inspect
> the code."
>
> You had been more constructive:
>   http://markmail.org/thread/a5jl6fkjjtm5qbsw
>
> Even if Ole may have picked the wrong example with Tomcat, the
> actual request is to be able to follow the execution of a fairly
> complex algorithm, like an optimizer, when applied to a fairly
> complex user's code, in order to figure out whether there is a
> problem; and if so, where it is (in the user's model, in the
> call, in the optimizer, whether there is a mismatch between the
> user's expectations and the capability of the selected algorithm,
> etc.)
>
> Ole's first example with an excerpt of the Levenberg-Marquardt
> implementation is actually a hit: a few years ago, a bug was found
> somewhere right around that same code:
>   https://issues.apache.org/jira/browse/MATH-406
> It's an example where logging is a valuable help in debugging.
> Another is the poor man's logging fiddling to track the cause of
> the erratic behaviour of one of the CI machines.
>
> Gilles
>
>
> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>>>
>>>
>>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>>
>>>> I disagree. Good tests, API contracts, exception management and
>>>> documentation can and should eliminate the need for cluttering
>>>> low-level library code with debug logging.
>>>>
>>>
>>> Logging could be viewed as clutter.  Constructed the right way,
>>> the logging statements could also be viewed as comments.
>>>
>>> I agree that good tests, API contracts, and in general keeping the
>>> design as minimalistic and simple as possible should be the first
>>> criteria to review before introducing logging.  When the code is
>>> trivial I leave logging out, unless I need to put in a few
>>> statements in order to track collaboration between components in
>>> an algorithm.
>>> Other times the method is as simple as it gets and I have to have
>>> logging.  For example take the LevenbergMarquardtOptimizer
>>> optimize() method.  It's atomic in the sense that what's in the
>>> method belongs in the method.  There are several loops within the
>>> main loop, etc. and tracking what's going, even with a observer
>>> being notified on each increment, would be far from elegant.
>>>
>>
>> Why, exactly do you need to "track what is going on?"  If you need
>> to do that as a user of the code, some kind of listener or API to
>> give you the information that you need is appropriate.  Dumping text
>> to an external resource to "solve" this usually indicates smelliness
>> somewhere - either in the library API or the client code.
>>
>>
>>> For example perhaps we want to see what's going on with the
>>> parameters in this small (5% of the method size) section of code:
>>>
>>
>> What parameters and where did they come from?  If from the client,
>> the client can validate them.  If the library needs to validate or
>> confirm suitability, then it should do that in code or via tests.
>>
>>>
>>>                 // compute the scaled predicted reduction
>>>                 // and the scaled directional derivative
>>>                 for (int j = 0; j < solvedCols; ++j) {
>>>                     int pj = permutation[j];
>>>                     double dirJ = lmDir[pj];
>>>                     work1[j] = 0;
>>>                     for (int i = 0; i <= j; ++i) {
>>>                         work1[i] += weightedJacobian[i][pj] * dirJ;
>>>                     }
>>>                 }
>>>
>>> If there is something wrong with this in production, the shortest
>>> path to figuring that out is reviewing a trace.  The longer path
>>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>>> the data.
>>>
>>> If we wanted to observe this section of code the observer would be
>>> looking at sub loops of of the optimize method.  So that's doable,
>>> but it creates an interface design for the observer that's
>>> cluttered with events corresponding to various low level algorithm
>>> details.
>>>
>>>
>>> Several times, I've been obliged to create a modified version of CM
>>>>> to introduce "print" statements (poor man's logging!) in order to
>>>>> figure out why my code did not do what it was supposed to.
>>>>>
>>>>
>>> It's pretty tragic that anyone of us should have to do this.  It's
>>> also wasteful, because if Gilles has to do this, then there's a
>>> good chance that others have to do it to.  The reason Tomcat logs
>>> at various levels is so that we can see what's going on in
>>> production and track down bugs.
>>>
>>
>> No.  Have a look at the Tomcat logging code.  It is mostly
>> initialization, shutdown and exceptions or warnings.  This is
>> necessary because tomcat is a container - there is no client
>> application to catch exceptions or get API results back.  The analog
>> for the kind of instrumentation you are proposing inside [math]
>> would be like tomcat larding itself up with debug logging throughout
>> the request processing lifecycle, which it does not do.   It is a
>> bad analogy in any case, because Tomcat is a container, which is 2
>> big steps up the processing chain from a low-level library.
>>
>> Phil
>>
>> Lets become one with the logging and make it into something that
>>> strengthens both code integrity and comprehensibility.  Everyone
>>> take take out your Feng Shui mat and do some deep breathing right
>>> now.
>>>
>>> Here again, tests, good design, code inspection are the way to go in
>>>> low-level components.  I have also spent a lot of time researching
>>>> bugs in [math], other Commons components and other complex systems.
>>>> My experience is a little different: excessive logging / debug code
>>>> for code that contains it often just tends to get in the way,
>>>>
>>> It's a very good point.  Sometimes we come across logging
>>> statements that are just noise.  Given how rigorous we are about
>>> reviewing everything though, I think a win win would be to limit
>>> the noise during code review, and pledge not to "Call our mom" in
>>> the middle of the code, etc.
>>>
>>> especially after it has rotted a bit.  Rather than adding more code
>>>> to maintain so that you can have less conceptual control over the
>>>> functional code, it is better, IMNSHO, to focus on making the
>>>> functional code as simple as possible with clean well-documented,
>>>> test-validated API contracts.
>>>>
>>>
>>> Totally agree.  I think this should be the first priority, and
>>> that logging should be used when there are no simple clean
>>> alternatives.
>>>
>>>
>>>> It also makes a code easier to debug while developing or
>>>>> modifying it
>>>>> (without resorting to poor man's logging, then deleting the
>>>>> "print",
>>>>> then reinstating them, then deleting them again, ad nauseam).
>>>>>
>>>> Pretty sure we have all been here.
>>>
>>> Cheers,
>>> - Ole
>>>
>>>
>>>
>>>>> Gilles
>>>>>
>>>>> [1] No quality or complexity judgment implied.
>>>>>
>>>>> Phil
>>>>>>
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> We have been discussing various ways to view what's happening
>>>>>>>>> internally
>>>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>>>> I know that
>>>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>>>> level
>>>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>>>> dependencies that
>>>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>>>> dealing with
>>>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>>>> SLF4J
>>>>>>>>> for
>>>>>>>>> logging.
>>>>>>>>>
>>>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>>>> made me a
>>>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>>>> for
>>>>>>>>> switching
>>>>>>>>> their logger out with SLF4J:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The general process I go through when working with many
>>>>>>>>> dependencies that
>>>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>>>> set of
>>>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>>>> someone has
>>>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>>>> could use
>>>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> - Ole
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> 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
>
>


-- 
OpenPGP: https://hasan.d8u.us/gpg.key
Sent from my mobile device
Envoyé de mon portable

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote:

I say something like: "I had to fork some CM class to insert
log statements."
You say something like: "No, you don't; write test or inspect
the code."

You had been more constructive:
   http://markmail.org/thread/a5jl6fkjjtm5qbsw

Even if Ole may have picked the wrong example with Tomcat, the
actual request is to be able to follow the execution of a fairly
complex algorithm, like an optimizer, when applied to a fairly
complex user's code, in order to figure out whether there is a
problem; and if so, where it is (in the user's model, in the
call, in the optimizer, whether there is a mismatch between the
user's expectations and the capability of the selected algorithm,
etc.)

Ole's first example with an excerpt of the Levenberg-Marquardt
implementation is actually a hit: a few years ago, a bug was found
somewhere right around that same code:
   https://issues.apache.org/jira/browse/MATH-406
It's an example where logging is a valuable help in debugging.
Another is the poor man's logging fiddling to track the cause of
the erratic behaviour of one of the CI machines.

Gilles

> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>>
>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>> I disagree. Good tests, API contracts, exception management and
>>> documentation can and should eliminate the need for cluttering
>>> low-level library code with debug logging.
>>
>> Logging could be viewed as clutter.  Constructed the right way,
>> the logging statements could also be viewed as comments.
>>
>> I agree that good tests, API contracts, and in general keeping the
>> design as minimalistic and simple as possible should be the first
>> criteria to review before introducing logging.  When the code is
>> trivial I leave logging out, unless I need to put in a few
>> statements in order to track collaboration between components in
>> an algorithm.
>> Other times the method is as simple as it gets and I have to have
>> logging.  For example take the LevenbergMarquardtOptimizer
>> optimize() method.  It's atomic in the sense that what's in the
>> method belongs in the method.  There are several loops within the
>> main loop, etc. and tracking what's going, even with a observer
>> being notified on each increment, would be far from elegant.
>
> Why, exactly do you need to "track what is going on?"  If you need
> to do that as a user of the code, some kind of listener or API to
> give you the information that you need is appropriate.  Dumping text
> to an external resource to "solve" this usually indicates smelliness
> somewhere - either in the library API or the client code.
>
>>
>> For example perhaps we want to see what's going on with the
>> parameters in this small (5% of the method size) section of code:
>
> What parameters and where did they come from?  If from the client,
> the client can validate them.  If the library needs to validate or
> confirm suitability, then it should do that in code or via tests.
>>
>>                 // compute the scaled predicted reduction
>>                 // and the scaled directional derivative
>>                 for (int j = 0; j < solvedCols; ++j) {
>>                     int pj = permutation[j];
>>                     double dirJ = lmDir[pj];
>>                     work1[j] = 0;
>>                     for (int i = 0; i <= j; ++i) {
>>                         work1[i] += weightedJacobian[i][pj] * dirJ;
>>                     }
>>                 }
>>
>> If there is something wrong with this in production, the shortest
>> path to figuring that out is reviewing a trace.  The longer path
>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>> the data.
>>
>> If we wanted to observe this section of code the observer would be
>> looking at sub loops of of the optimize method.  So that's doable,
>> but it creates an interface design for the observer that's
>> cluttered with events corresponding to various low level algorithm
>> details.
>>
>>
>>>> Several times, I've been obliged to create a modified version of 
>>>> CM
>>>> to introduce "print" statements (poor man's logging!) in order to
>>>> figure out why my code did not do what it was supposed to.
>>
>> It's pretty tragic that anyone of us should have to do this.  It's
>> also wasteful, because if Gilles has to do this, then there's a
>> good chance that others have to do it to.  The reason Tomcat logs
>> at various levels is so that we can see what's going on in
>> production and track down bugs.
>
> No.  Have a look at the Tomcat logging code.  It is mostly
> initialization, shutdown and exceptions or warnings.  This is
> necessary because tomcat is a container - there is no client
> application to catch exceptions or get API results back.  The analog
> for the kind of instrumentation you are proposing inside [math]
> would be like tomcat larding itself up with debug logging throughout
> the request processing lifecycle, which it does not do.   It is a
> bad analogy in any case, because Tomcat is a container, which is 2
> big steps up the processing chain from a low-level library.
>
> Phil
>
>> Lets become one with the logging and make it into something that
>> strengthens both code integrity and comprehensibility.  Everyone
>> take take out your Feng Shui mat and do some deep breathing right
>> now.
>>
>>> Here again, tests, good design, code inspection are the way to go 
>>> in
>>> low-level components.  I have also spent a lot of time researching
>>> bugs in [math], other Commons components and other complex systems.
>>> My experience is a little different: excessive logging / debug code
>>> for code that contains it often just tends to get in the way,
>> It's a very good point.  Sometimes we come across logging
>> statements that are just noise.  Given how rigorous we are about
>> reviewing everything though, I think a win win would be to limit
>> the noise during code review, and pledge not to "Call our mom" in
>> the middle of the code, etc.
>>
>>> especially after it has rotted a bit.  Rather than adding more code
>>> to maintain so that you can have less conceptual control over the
>>> functional code, it is better, IMNSHO, to focus on making the
>>> functional code as simple as possible with clean well-documented,
>>> test-validated API contracts.
>>
>> Totally agree.  I think this should be the first priority, and
>> that logging should be used when there are no simple clean
>> alternatives.
>>
>>>
>>>> It also makes a code easier to debug while developing or
>>>> modifying it
>>>> (without resorting to poor man's logging, then deleting the
>>>> "print",
>>>> then reinstating them, then deleting them again, ad nauseam).
>> Pretty sure we have all been here.
>>
>> Cheers,
>> - Ole
>>
>>
>>>>
>>>> Gilles
>>>>
>>>> [1] No quality or complexity judgment implied.
>>>>
>>>>> Phil
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
>>>>>>> <ol...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> We have been discussing various ways to view what's happening
>>>>>>>> internally
>>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>>> I know that
>>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>>> level
>>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>>> dependencies that
>>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>>> dealing with
>>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>>> SLF4J
>>>>>>>> for
>>>>>>>> logging.
>>>>>>>>
>>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>>> made me a
>>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>>> for
>>>>>>>> switching
>>>>>>>> their logger out with SLF4J:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The general process I go through when working with many
>>>>>>>> dependencies that
>>>>>>>> might use commons-logging instead of SLF4J looks something 
>>>>>>>> like
>>>>>>>> this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>>> set of
>>>>>>>> dependencies.  At this point the fix should be a permanent.  
>>>>>>>> If
>>>>>>>> someone has
>>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>>> could use
>>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Ole
>>>>
>>>> 
>>>> ---------------------------------------------------------------------
>>>>
>>>> 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

Re: [Math] Utilitzation of SLF4J?

[Phil Steitz <ph...@gmail.com>]

On 9/25/15 11:01 AM, Ole Ersoy wrote:
>
>
> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>> I disagree. Good tests, API contracts, exception management and
>> documentation can and should eliminate the need for cluttering
>> low-level library code with debug logging.
>
> Logging could be viewed as clutter.  Constructed the right way,
> the logging statements could also be viewed as comments.
>
> I agree that good tests, API contracts, and in general keeping the
> design as minimalistic and simple as possible should be the first
> criteria to review before introducing logging.  When the code is
> trivial I leave logging out, unless I need to put in a few
> statements in order to track collaboration between components in
> an algorithm.  
> Other times the method is as simple as it gets and I have to have
> logging.  For example take the LevenbergMarquardtOptimizer
> optimize() method.  It's atomic in the sense that what's in the
> method belongs in the method.  There are several loops within the
> main loop, etc. and tracking what's going, even with a observer
> being notified on each increment, would be far from elegant.

Why, exactly do you need to "track what is going on?"  If you need
to do that as a user of the code, some kind of listener or API to
give you the information that you need is appropriate.  Dumping text
to an external resource to "solve" this usually indicates smelliness
somewhere - either in the library API or the client code.

>
> For example perhaps we want to see what's going on with the
> parameters in this small (5% of the method size) section of code:

What parameters and where did they come from?  If from the client,
the client can validate them.  If the library needs to validate or
confirm suitability, then it should do that in code or via tests.
>
>                 // compute the scaled predicted reduction
>                 // and the scaled directional derivative
>                 for (int j = 0; j < solvedCols; ++j) {
>                     int pj = permutation[j];
>                     double dirJ = lmDir[pj];
>                     work1[j] = 0;
>                     for (int i = 0; i <= j; ++i) {
>                         work1[i] += weightedJacobian[i][pj] * dirJ;
>                     }
>                 }
>
> If there is something wrong with this in production, the shortest
> path to figuring that out is reviewing a trace.  The longer path
> is to stop the server.  Grab the data.  Open up a debugger.  Run
> the data.
>
> If we wanted to observe this section of code the observer would be
> looking at sub loops of of the optimize method.  So that's doable,
> but it creates an interface design for the observer that's
> cluttered with events corresponding to various low level algorithm
> details.
>
>
>>> Several times, I've been obliged to create a modified version of CM
>>> to introduce "print" statements (poor man's logging!) in order to
>>> figure out why my code did not do what it was supposed to.
>
> It's pretty tragic that anyone of us should have to do this.  It's
> also wasteful, because if Gilles has to do this, then there's a
> good chance that others have to do it to.  The reason Tomcat logs
> at various levels is so that we can see what's going on in
> production and track down bugs.

No.  Have a look at the Tomcat logging code.  It is mostly
initialization, shutdown and exceptions or warnings.  This is
necessary because tomcat is a container - there is no client
application to catch exceptions or get API results back.  The analog
for the kind of instrumentation you are proposing inside [math]
would be like tomcat larding itself up with debug logging throughout
the request processing lifecycle, which it does not do.   It is a
bad analogy in any case, because Tomcat is a container, which is 2
big steps up the processing chain from a low-level library.

Phil

> Lets become one with the logging and make it into something that
> strengthens both code integrity and comprehensibility.  Everyone
> take take out your Feng Shui mat and do some deep breathing right
> now.
>
>> Here again, tests, good design, code inspection are the way to go in
>> low-level components.  I have also spent a lot of time researching
>> bugs in [math], other Commons components and other complex systems.
>> My experience is a little different: excessive logging / debug code
>> for code that contains it often just tends to get in the way,
> It's a very good point.  Sometimes we come across logging
> statements that are just noise.  Given how rigorous we are about
> reviewing everything though, I think a win win would be to limit
> the noise during code review, and pledge not to "Call our mom" in
> the middle of the code, etc.
>
>> especially after it has rotted a bit.  Rather than adding more code
>> to maintain so that you can have less conceptual control over the
>> functional code, it is better, IMNSHO, to focus on making the
>> functional code as simple as possible with clean well-documented,
>> test-validated API contracts.
>
> Totally agree.  I think this should be the first priority, and
> that logging should be used when there are no simple clean
> alternatives.
>
>>
>>> It also makes a code easier to debug while developing or
>>> modifying it
>>> (without resorting to poor man's logging, then deleting the
>>> "print",
>>> then reinstating them, then deleting them again, ad nauseam).
> Pretty sure we have all been here.
>
> Cheers,
> - Ole
>
>
>>>
>>> Gilles
>>>
>>> [1] No quality or complexity judgment implied.
>>>
>>>> Phil
>>>>>
>>>>> Gilles
>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> We have been discussing various ways to view what's happening
>>>>>>> internally
>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>> I know that
>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>> level
>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>> dependencies that
>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>> dealing with
>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>> SLF4J
>>>>>>> for
>>>>>>> logging.
>>>>>>>
>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>> made me a
>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>> for
>>>>>>> switching
>>>>>>> their logger out with SLF4J:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The general process I go through when working with many
>>>>>>> dependencies that
>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>> this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>> set of
>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>> someone has
>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>> could use
>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> - Ole
>>>
>>> ---------------------------------------------------------------------
>>>
>>> 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

Re: [Math] Utilitzation of SLF4J?

[Ole Ersoy <ol...@gmail.com>]

On 09/25/2015 11:34 AM, Phil Steitz wrote:
> I disagree. Good tests, API contracts, exception management and documentation can and should eliminate the need for cluttering low-level library code with debug logging.

Logging could be viewed as clutter.  Constructed the right way, the logging statements could also be viewed as comments.

I agree that good tests, API contracts, and in general keeping the design as minimalistic and simple as possible should be the first criteria to review before introducing logging.  When the code is trivial I leave logging out, unless I need to put in a few statements in order to track collaboration between components in an algorithm.  Other times the method is as simple as it gets and I have to have logging.  For example take the LevenbergMarquardtOptimizer optimize() method.  It's atomic in the sense that what's in the method belongs in the method.  There are several loops within the main loop, etc. and tracking what's going, even with a observer being notified on each increment, would be far from elegant.

For example perhaps we want to see what's going on with the parameters in this small (5% of the method size) section of code:

                 // compute the scaled predicted reduction
                 // and the scaled directional derivative
                 for (int j = 0; j < solvedCols; ++j) {
                     int pj = permutation[j];
                     double dirJ = lmDir[pj];
                     work1[j] = 0;
                     for (int i = 0; i <= j; ++i) {
                         work1[i] += weightedJacobian[i][pj] * dirJ;
                     }
                 }

If there is something wrong with this in production, the shortest path to figuring that out is reviewing a trace.  The longer path is to stop the server.  Grab the data.  Open up a debugger.  Run the data.

If we wanted to observe this section of code the observer would be looking at sub loops of of the optimize method.  So that's doable, but it creates an interface design for the observer that's cluttered with events corresponding to various low level algorithm details.


>> Several times, I've been obliged to create a modified version of CM
>> to introduce "print" statements (poor man's logging!) in order to
>> figure out why my code did not do what it was supposed to.

It's pretty tragic that anyone of us should have to do this.  It's also wasteful, because if Gilles has to do this, then there's a good chance that others have to do it to.  The reason Tomcat logs at various levels is so that we can see what's going on in production and track down bugs.  Lets become one with the logging and make it into something that strengthens both code integrity and comprehensibility.  Everyone take take out your Feng Shui mat and do some deep breathing right now.

> Here again, tests, good design, code inspection are the way to go in
> low-level components.  I have also spent a lot of time researching
> bugs in [math], other Commons components and other complex systems.
> My experience is a little different: excessive logging / debug code
> for code that contains it often just tends to get in the way,
It's a very good point.  Sometimes we come across logging statements that are just noise.  Given how rigorous we are about reviewing everything though, I think a win win would be to limit the noise during code review, and pledge not to "Call our mom" in the middle of the code, etc.

> especially after it has rotted a bit.  Rather than adding more code
> to maintain so that you can have less conceptual control over the
> functional code, it is better, IMNSHO, to focus on making the
> functional code as simple as possible with clean well-documented,
> test-validated API contracts.

Totally agree.  I think this should be the first priority, and that logging should be used when there are no simple clean alternatives.

>
>> It also makes a code easier to debug while developing or modifying it
>> (without resorting to poor man's logging, then deleting the "print",
>> then reinstating them, then deleting them again, ad nauseam).
Pretty sure we have all been here.

Cheers,
- Ole


>>
>> Gilles
>>
>> [1] No quality or complexity judgment implied.
>>
>>> Phil
>>>>
>>>> Gilles
>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> We have been discussing various ways to view what's happening
>>>>>> internally
>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>> I know that
>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>> level
>>>>>> dependency, therefore it should minimize the transitive
>>>>>> dependencies that
>>>>>> it introduces.  The Java community has adopted many means of
>>>>>> dealing with
>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>> for
>>>>>> logging.
>>>>>>
>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>> made me a
>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>> switching
>>>>>> their logger out with SLF4J:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>
>>>>>>
>>>>>>
>>>>>> The general process I go through when working with many
>>>>>> dependencies that
>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>> this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>
>>>>>>
>>>>>>
>>>>>> With JDK9 individual modules can define their own isolated set of
>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>> someone has
>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>> could use
>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> - Ole
>>
>> ---------------------------------------------------------------------
>> 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

Re: [Math] Utilitzation of SLF4J?

[Phil Steitz <ph...@gmail.com>]

On 9/25/15 8:09 AM, 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 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".
>
> If there are now well-formed answers proving that the fear was
> unfounded, that is also a change.
>
> IMO, logging is quite important for any "non-obvious" code.[1]
> [I'm again stating that, in that respect, CM is not like the other
> "Commmons" components.]

I disagree.  Good tests, API contracts, exception management and
documentation can and should eliminate the need for cluttering
low-level library code with debug logging.
>
> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.

Here again, tests, good design, code inspection are the way to go in
low-level components.  I have also spent a lot of time researching
bugs in [math], other Commons components and other complex systems. 
My experience is a little different: excessive logging / debug code
for code that contains it often just tends to get in the way,
especially after it has rotted a bit.  Rather than adding more code
to maintain so that you can have less conceptual control over the
functional code, it is better, IMNSHO, to focus on making the
functional code as simple as possible with clean well-documented,
test-validated API contracts.  

> It also makes a code easier to debug while developing or modifying it
> (without resorting to poor man's logging, then deleting the "print",
> then reinstating them, then deleting them again, ad nauseam).
>
> Gilles
>
> [1] No quality or complexity judgment implied.
>
>> Phil
>>>
>>>
>>> Gilles
>>>
>>>> Thomas
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> We have been discussing various ways to view what's happening
>>>>> internally
>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>> I know that
>>>>> this was discussed earlier and it was decided that CM is a low
>>>>> level
>>>>> dependency, therefore it should minimize the transitive
>>>>> dependencies that
>>>>> it introduces.  The Java community has adopted many means of
>>>>> dealing with
>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>> for
>>>>> logging.
>>>>>
>>>>> I know that JBoss introduced its own logging system, and this
>>>>> made me a
>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>> switching
>>>>> their logger out with SLF4J:
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>
>>>>>
>>>>>
>>>>> The general process I go through when working with many
>>>>> dependencies that
>>>>> might use commons-logging instead of SLF4J looks something like
>>>>> this:
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>
>>>>>
>>>>>
>>>>> With JDK9 individual modules can define their own isolated set of
>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>> someone has
>>>>> has a very intricate scenario that we have not yet seen, they
>>>>> could use
>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers,
>>>>> - Ole
>
>
> ---------------------------------------------------------------------
> 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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

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

If there are now well-formed answers proving that the fear was
unfounded, that is also a change.

IMO, logging is quite important for any "non-obvious" code.[1]
[I'm again stating that, in that respect, CM is not like the other
"Commmons" components.]

Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.
It also makes a code easier to debug while developing or modifying it
(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).

Gilles

[1] No quality or complexity judgment implied.

> Phil
>>
>>
>> Gilles
>>
>>> Thomas
>>>
>>>
>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> We have been discussing various ways to view what's happening
>>>> internally
>>>> with algorithms, and the topic of including SLF4J has come up.
>>>> I know that
>>>> this was discussed earlier and it was decided that CM is a low
>>>> level
>>>> dependency, therefore it should minimize the transitive
>>>> dependencies that
>>>> it introduces.  The Java community has adopted many means of
>>>> dealing with
>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>> for
>>>> logging.
>>>>
>>>> I know that JBoss introduced its own logging system, and this
>>>> made me a
>>>> bit nervous about this suggestion, so I looked up strategies for
>>>> switching
>>>> their logger out with SLF4J:
>>>>
>>>>
>>>> 
>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>
>>>>
>>>> The general process I go through when working with many
>>>> dependencies that
>>>> might use commons-logging instead of SLF4J looks something like
>>>> this:
>>>>
>>>>
>>>> 
>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>
>>>>
>>>> With JDK9 individual modules can define their own isolated set of
>>>> dependencies.  At this point the fix should be a permanent.  If
>>>> someone has
>>>> has a very intricate scenario that we have not yet seen, they
>>>> could use
>>>> (And probably should use) OSGi to isolate dependencies.
>>>>
>>>> WDYT?
>>>>
>>>> Cheers,
>>>> - Ole


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

Re: [Math] Utilitzation of SLF4J?

[Phil Steitz <ph...@gmail.com>]

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?

Phil
>
>
> Gilles
>
>> Thomas
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up. 
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>
>>>
>>> With JDK9 individual modules can define their own isolated set of
>>> dependencies.  At this point the fix should be a permanent.  If
>>> someone has
>>> has a very intricate scenario that we have not yet seen, they
>>> could use
>>> (And probably should use) OSGi to isolate dependencies.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> - Ole
>
>
> ---------------------------------------------------------------------
> 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

Re: [Math] Utilitzation of SLF4J?

[Gilles <gi...@harfang.homelinux.org>]

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?


Gilles

> Thomas
>
>
> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com> 
> wrote:
>
>> Hello,
>>
>> We have been discussing various ways to view what's happening 
>> internally
>> with algorithms, and the topic of including SLF4J has come up.  I 
>> know that
>> this was discussed earlier and it was decided that CM is a low level
>> dependency, therefore it should minimize the transitive dependencies 
>> that
>> it introduces.  The Java community has adopted many means of dealing 
>> with
>> potential logging conflicts, so I'm requesting that we use SLF4J for
>> logging.
>>
>> I know that JBoss introduced its own logging system, and this made 
>> me a
>> bit nervous about this suggestion, so I looked up strategies for 
>> switching
>> their logger out with SLF4J:
>>
>> 
>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>
>> The general process I go through when working with many dependencies 
>> that
>> might use commons-logging instead of SLF4J looks something like 
>> this:
>>
>> 
>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>
>> With JDK9 individual modules can define their own isolated set of
>> dependencies.  At this point the fix should be a permanent.  If 
>> someone has
>> has a very intricate scenario that we have not yet seen, they could 
>> use
>> (And probably should use) OSGi to isolate dependencies.
>>
>> WDYT?
>>
>> Cheers,
>> - Ole


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

Re: [Math] Utilitzation of SLF4J?

[Gary Gregory <ga...@gmail.com>]

On Fri, Sep 25, 2015 at 8:50 AM, Phil Steitz <ph...@gmail.com> wrote:

> On 9/25/15 8:45 AM, Ole Ersoy wrote:
> > Hi Thomas,
> >
> > On 09/25/2015 08:54 AM, 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.
> > Well it has to be SLF4J because that's the one I'm most familiar
> > with :).  We did discuss having observers that can listen in on
> > increment events that algorithms publish.  This would provide a
> > dependency free method for doing so with one drawback.  Now
> > everyone that wants the algorithm to log has to implement logging.
>
> This is the right approach, IMO, for reasons that have been stated
> in the archives.  Has more as much to do with separation of concerns
> and clean API contracts as dependencies and conflicts.
>

Note that Log4j 2 (we just released 2.4) has a clean separation between
logging API and implementations, including it's own of course.

We are also an active group of developers here to help you should you it!
:-)

https://logging.apache.org/log4j/2.x/index.html

Gary


>
> Phil
> >
> >> 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).
> > Would you be upset if it was SLF4J?  This is minor, but I like the
> > @SLF4J annotation that Lombok provides.
> >
> >>
> >> btw. the same discussion has been done for other commons
> >> components as
> >> well, and the result usually was: do not add logging
> > I think for the reason that commons should not introduce
> > transitive dependencies?  This has been solved fairly well (Below).
> >
> > Cheers,
> > - Ole
> >
> >>
> >> Thomas
> >>
> >>
> >> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> We have been discussing various ways to view what's happening
> >>> internally
> >>> with algorithms, and the topic of including SLF4J has come up.
> >>> I know that
> >>> this was discussed earlier and it was decided that CM is a low
> >>> level
> >>> dependency, therefore it should minimize the transitive
> >>> dependencies that
> >>> it introduces.  The Java community has adopted many means of
> >>> dealing with
> >>> potential logging conflicts, so I'm requesting that we use SLF4J
> >>> for
> >>> logging.
> >>>
> >>> I know that JBoss introduced its own logging system, and this
> >>> made me a
> >>> bit nervous about this suggestion, so I looked up strategies for
> >>> switching
> >>> their logger out with SLF4J:
> >>>
> >>>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
> >>>
> >>>
> >>> The general process I go through when working with many
> >>> dependencies that
> >>> might use commons-logging instead of SLF4J looks something like
> >>> this:
> >>>
> >>>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
> >>>
> >>>
> >>> With JDK9 individual modules can define their own isolated set of
> >>> dependencies.  At this point the fix should be a permanent.  If
> >>> someone has
> >>> has a very intricate scenario that we have not yet seen, they
> >>> could use
> >>> (And probably should use) OSGi to isolate dependencies.
> >>>
> >>> WDYT?
> >>>
> >>> Cheers,
> >>> - Ole
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>>
> >>> 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
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Utilitzation of SLF4J?

[Phil Steitz <ph...@gmail.com>]

On 9/25/15 8:45 AM, Ole Ersoy wrote:
> Hi Thomas,
>
> On 09/25/2015 08:54 AM, 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.
> Well it has to be SLF4J because that's the one I'm most familiar
> with :).  We did discuss having observers that can listen in on
> increment events that algorithms publish.  This would provide a
> dependency free method for doing so with one drawback.  Now
> everyone that wants the algorithm to log has to implement logging.

This is the right approach, IMO, for reasons that have been stated
in the archives.  Has more as much to do with separation of concerns
and clean API contracts as dependencies and conflicts.

Phil
>
>> 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).
> Would you be upset if it was SLF4J?  This is minor, but I like the
> @SLF4J annotation that Lombok provides.
>
>>
>> btw. the same discussion has been done for other commons
>> components as
>> well, and the result usually was: do not add logging
> I think for the reason that commons should not introduce
> transitive dependencies?  This has been solved fairly well (Below).
>
> Cheers,
> - Ole
>
>>
>> Thomas
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up. 
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>
>>>
>>> With JDK9 individual modules can define their own isolated set of
>>> dependencies.  At this point the fix should be a permanent.  If
>>> someone has
>>> has a very intricate scenario that we have not yet seen, they
>>> could use
>>> (And probably should use) OSGi to isolate dependencies.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> - Ole
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> 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

Re: [Math] Utilitzation of SLF4J?

[Ole Ersoy <ol...@gmail.com>]

Hi Thomas,

On 09/25/2015 08:54 AM, 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.
Well it has to be SLF4J because that's the one I'm most familiar with :).  We did discuss having observers that can listen in on increment events that algorithms publish.  This would provide a dependency free method for doing so with one drawback.  Now everyone that wants the algorithm to log has to implement logging.

> 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).
Would you be upset if it was SLF4J?  This is minor, but I like the @SLF4J annotation that Lombok provides.

>
> btw. the same discussion has been done for other commons components as
> well, and the result usually was: do not add logging
I think for the reason that commons should not introduce transitive dependencies?  This has been solved fairly well (Below).

Cheers,
- Ole

>
> Thomas
>
>
> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com> wrote:
>
>> Hello,
>>
>> We have been discussing various ways to view what's happening internally
>> with algorithms, and the topic of including SLF4J has come up.  I know that
>> this was discussed earlier and it was decided that CM is a low level
>> dependency, therefore it should minimize the transitive dependencies that
>> it introduces.  The Java community has adopted many means of dealing with
>> potential logging conflicts, so I'm requesting that we use SLF4J for
>> logging.
>>
>> I know that JBoss introduced its own logging system, and this made me a
>> bit nervous about this suggestion, so I looked up strategies for switching
>> their logger out with SLF4J:
>>
>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>
>> The general process I go through when working with many dependencies that
>> might use commons-logging instead of SLF4J looks something like this:
>>
>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>
>> With JDK9 individual modules can define their own isolated set of
>> dependencies.  At this point the fix should be a permanent.  If someone has
>> has a very intricate scenario that we have not yet seen, they could use
>> (And probably should use) OSGi to isolate dependencies.
>>
>> WDYT?
>>
>> Cheers,
>> - Ole
>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: [Math] Utilitzation of SLF4J?

[Thomas Neidhart <th...@gmail.com>]

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

btw. the same discussion has been done for other commons components as
well, and the result usually was: do not add logging

Thomas


On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ol...@gmail.com> wrote:

> Hello,
>
> We have been discussing various ways to view what's happening internally
> with algorithms, and the topic of including SLF4J has come up.  I know that
> this was discussed earlier and it was decided that CM is a low level
> dependency, therefore it should minimize the transitive dependencies that
> it introduces.  The Java community has adopted many means of dealing with
> potential logging conflicts, so I'm requesting that we use SLF4J for
> logging.
>
> I know that JBoss introduced its own logging system, and this made me a
> bit nervous about this suggestion, so I looked up strategies for switching
> their logger out with SLF4J:
>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>
> The general process I go through when working with many dependencies that
> might use commons-logging instead of SLF4J looks something like this:
>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>
> With JDK9 individual modules can define their own isolated set of
> dependencies.  At this point the fix should be a permanent.  If someone has
> has a very intricate scenario that we have not yet seen, they could use
> (And probably should use) OSGi to isolate dependencies.
>
> WDYT?
>
> Cheers,
> - Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>