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" <l...@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 <l...@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 <
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?
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
<mailto:
dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
<mailto:
dev-h...@commons.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
