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
<gil...@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
<gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
