commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [Math] Utilitzation of SLF4J?
Date Sat, 26 Sep 2015 22:14:32 GMT
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 <luc@spaceroots.org> wrote:
> 
> Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <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.
> 
> 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 <luc@spaceroots.org>
wrote:
>>>>> 
>>>>> Le 26/09/2015 18:42, Gilles a écrit :
>>>>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>>>>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>>>>>>> On 09/26/2015 01:11 PM, Gilles wrote:
>>>>>>>>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>>>>>>>>>> On 09/26/2015 02:33 AM, Gilles wrote:
>>>>>>>>>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan
wrote:
>>>>>>>>>>>> On 25 September 2015 at 16:47, Gilles <
>> gilles@harfang.homelinux.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas
Neidhart wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Sep 25, 2015 at 5:09 PM,
Gilles
>>>>>>>>>>>>>> <gilles@harfang.homelinux.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, 25 Sep 2015 07:28:48 -0700,
Phil Steitz wrote:
>>>>>>>>>>>>>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>>>>>>>>>>>>> On Fri, 25 Sep 2015 15:54:14
+0200, Thomas Neidhart wrote:
>>>>>>>>>>>>>>>>> Hi Ole,
>>>>>>>>>>>>>>>>>> for a start, I think
you are asking the wrong question.
>>>>>>>>>>>>>>>>>> First of all we need
to agree that we want to add some
>> kind of
>>>>>>>>>>>>>>>>>> logging
>>>>>>>>>>>>>>>>>> facility to CM.
>>>>>>>>>>>>>>>>>> If the outcome is
positive, there are a handful of
>>>>>>>>>>>>>>>>>> alternatives,
>>>>>>>>>>>>>>>>>> some of
>>>>>>>>>>>>>>>>>> them more viable
than slf4j in the context of CM (e.g.
>> JUL or
>>>>>>>>>>>>>>>>>> commons-logging).
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Could someone summarize
why those alternatives were deemed
>>>>>>>>>>>>>>>>> "more
>>>>>>>>>>>>>>>>> viable"?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> btw. the same discussion
has been done for other commons
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> components as
>>>>>>>>>>>>>>>>>> well, and the result
usually was: do not add logging
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> What was the rationale?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Look at the archives.  We
have discussed this multiple times
>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>> past in [math] and each time
came to the conclusion that
>> Thomas
>>>>>>>>>>>>>>>> succinctly states above.
 What has changed now?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We also discussed several times
to stick with Java 5.
>>>>>>>>>>>>>>> Fortunately, that has changed.
[Although sticking with Java
>> 7 is
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> a bad decision IMHO.]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> As for logging, IIRC, the sole
argument was "no dependency"
>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>> (IIRC) of the potential "JAR
hell".
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> that's not correct. The decision
to not include any
>>>>>>>>>>>>>> dependencies has
>>>>>>>>>>>>>> nothing to do with "JAR hell".
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> Although I can't find it now, I'm pretty
sure that I more than
>> once
>>>>>>>>>>>>> got such an answer.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In order to prevent JAR hell, commons
components strictly stick
>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> "Versioning guidelines" [1]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> I can't see how it relates.
>>>>>>>>>>>>> But if you mean that no JAR hell can
emerge from using a
>> logging
>>>>>>>>>>>>> framework,
>>>>>>>>>>>>> then that's good news.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The no-dependency rule is more related
to the proposal of the
>>>>>>>>>>>>> component,
>>>>>>>>>>>>>> see [2]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for the reminder; in that document,
we read:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> (1) Scope of the Package
>>>>>>>>>>>>>  [...]
>>>>>>>>>>>>>  5. Limited dependencies. No external
dependencies beyond
>> Commons
>>>>>>>>>>>>> components and the JDK
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So we are fine if use "Log4j 2" as kindly
offered by Gary.
>>>>>>>>>> log4j is not a commons component btw.
>>>>>>>>> Too bad for me. :-/
>>>>>>>>> Case resolved, then, by the argument of authority?
>>>>>>>> I just pointed out that log4j is not a commons component
and did not
>>>>>>>> imply anything else.
>>>>>>>> 
>>>>>>>>> "Commons" is OK but not another Apache project, by virtue
of a
>>>>>>>>> document that still refers to "JDK 1.2", "CVS", "Bugzilla"
(not to
>>>>>>>>> mention that the "scope" of CM currently goes well beyond
"the most
>>>>>>>>> common practical problems not immediately available in
the Java
>>>>>>>>> programming language")...
>>>>>>>>> 
>>>>>>>>> What's the _technical_ rationale for accepting this dependency
and
>>>>>>>>> not accepting that dependency?
>>>>>>>>> 
>>>>>>>>>> I have not seen a single example of a useful logging
message that
>>>>>>>>>> could
>>>>>>>>>> be added to commons-math, but we are already discussing
which
>>>>>>>>>> framework
>>>>>>>>>> to use.
>>>>>>>>> If it is not useful to you, why would you conclude that
it is not
>>>>>>>>> useful to others?
>>>>>>>>> 
>>>>>>>>> At the cost of repeating myself, once more, the use-case
is not
>>>>>>>>> primarily about debugging CM, but sometimes one could
need to
>> assess
>>>>>>>>> how a "non-obvious" CM algorithm responds to an application's
>> request.
>>>>>>>>> I've clearly expressed that use-case in a previous message.
>>>>>>>>> 
>>>>>>>>> Another example: I have a class that wraps a CM root
solver; it is
>>>>>>>>> stuffed with log statements because the message contained
in the
>>>>>>>>> "NoBracketingException" was utterly insufficient (and
plainly
>>>>>>>>> misleading due the default formatting of numbers) to
figure out why
>>>>>>>>> certain calls succeeded and others not.
>>>>>>>>> It's a problem (or a limitation) in the application,
but in the
>>>>>>>>> absence of other clues, tracing the solver could help
figure out a
>>>>>>>>> workaround.
>>>>>>>>> The alternative to the "logging" approach, would have
been to
>> include
>>>>>>>>> a precondition check before calling the solver, that
would in
>> effect
>>>>>>>>> duplicate the bracketing check done inside the solver.
Given the
>> vast
>>>>>>>>> amount of cases where the code ran smoothly, this is
clearly a
>>>>>>>>> sub-optimal solution as compared to turning logging on
and rerun
>> the
>>>>>>>>> case that led to a crash.
>>>>>>>>> 
>>>>>>>>> What can I say more about the usefulness (for a "low-tech"
person
>>>>>>>>> like me) than the intro here:
>>>>>>>>> http://logging.apache.org/log4j/2.x/manual/index.html
>>>>>>>>> ?
>>>>>>>>> 
>>>>>>>>>> The examples with println debugging are not valid
imho, because
>> how do
>>>>>>>>>> you know in advance what you will need to log in
order to
>> successfully
>>>>>>>>>> debug some piece of code and such low-level information
should
>> not be
>>>>>>>>>> captured in logs anyway.
>>>>>>>>> Why are there several log levels?  Low-level info can
be routed to
>>>>>>>>> "DEBUG" or "TRACE".
>>>>>>>>> As Ole put it quite eloquently, logging is a safety net
that we
>> hope
>>>>>>>>> we'll never need, until we do.
>>>>>>>>> 
>>>>>>>>> Each layer of an application has its own notion of what
is the
>>>>>>>>> appropriate log level. What is "INFO" for some low-level
library
>>>>>>>>> will very probably not be so for most applications that
use the
>>>>>>>>> library.
>>>>>>>>> Setting levels per package or class takes care of that:
it's the
>>>>>>>>> library's *user* who chooses what is useful in the current
>> situation,
>>>>>>>>> not the library's developer.
>>>>>>>>> In the context of that asynchronous collaboration, the
role of the
>>>>>>>>> library's developer is to carefully choose what *could*
be
>>>>>>>>> interesting, if the need should arise.
>>>>>>>>> 
>>>>>>>>> So, can we eventually discuss the _technical_ arguments
against
>>>>>>>>> logging inside CM, rather than personal opinion?
>>>>>>>> again, what I want to see is an example what *should* be
logged in
>> the
>>>>>>>> case of an algorithm. Take the LevenbergMarquardtOptimizer
as an
>>>>>>>> example:
>>>>>>>> 
>>>>>>>> * what did you log using System.out.println()?
>>>>>>>> * the algo computes a lot of internal data, which of these
is
>>>>>>>> interesting for debugging problems or for general logging?
>>>>>>>> * there are various branches the algo can take, are just
some
>>>>>>>> interesting to log, or all of them?
>>>>>>>> 
>>>>>>>> the use-cases presented so far were mainly about debugging
specific
>>>>>>>> problems, and I am *strongly* against adding logging information
>> just
>>>>>>>> for this purpose as you are clearly facing a dilemma here:
>>>>>>>> 
>>>>>>>> you have to log *everything* an algo does as otherwise you
might
>> miss
>>>>>>>> the part that creates problems
>>>>>>>> 
>>>>>>>> but logging everything is not useful for a standard user
of the
>> library
>>>>>>>> so it contradicts the original proposal to include logging
>>>>>>>> 
>>>>>>>> Again, CM is not an application where you need to log what
it is
>> doing,
>>>>>>>> but a bunch of algorithms and utility methods to perform
certain
>>>>>>>> calculations. I fail to see the need to add logging. What
could be
>>>>>>>> useful, and we had requests like that in the past, is to
observe the
>>>>>>>> state of a certain algorithm and to decide how to proceed
in certain
>>>>>>>> cases.
>>>>>>>> 
>>>>>>>> That is useful for users.
>>>>>>>> 
>>>>>>>> Another useful addition would be to add more aggressive assertions.
>> If
>>>>>>>> one user encounters a problem, he/she could run the application
with
>>>>>>>> assertions enabled and spot potential problems e.g. due to
wrong
>> input.
>>>>>>>> 
>>>>>>>> Logging is a solution for a non existing problem imho.
>>>>>>>> Logging will not avoid the need to debug CM in case of problems
>> imho.
>>>>>>> 
>>>>>>> +1
>>>>>>> The other thing I would add is that the one place where it does
make
>>>>>>> sense to dump text is in exception error messages, which is a
place
>>>>>>> where I think we could really improve things.  Fortunately, that
is
>>>>>>> fairly easily done.
>>>>>>> 
>>>>>>> I have seen nothing in this thread to convince me that adding
>>>>>>> logging in [math] will be net positive for either those of us
who
>>>>>>> maintain the component or for users.  If we are not providing
clear
>>>>>>> exception error messages and/or APIs (with complete documentation)
>>>>>>> so that users can understand what they need to debug their
>>>>>>> applications, then we should focus on solving those problems.
>>>>>>> 
>>>>>>> Phil
>>>>>> 
>>>>>> First, you carefully do not reply to any of the concrete arguments
>>>>>> given in this thread, second you give a conclusion to an issue not
>>>>>> reported in this thread: exceptions and logging do not provide the
>>>>>> same service.
>>>>>> 
>>>>>> At least, I'd wish that people sharing their own opinion (it's
>>>>>> nothing more since _zero_ technical argument against logging have
>>>>>> been put forth) stop taking the collective "users" on their side.
>>>>>> As for *actual* users/maintainers, Ole and I have a need, while
>>>>>> Thomas and you haven't.  Those are all the facts that exist until
>>>>>> now.
>>>>>> 
>>>>>> In such a situation, what do we do as a project; maintain the status
>>>>>> quo, or try for a change?
>>>>>> On numerous occasions over the years, the status quo was enforced;
>>>>>> and I don't see that it benefited the project in terms of new
>>>>>> contributors.
>>>>>> So I'm +1 for trying to change, for a change.
>>>>> 
>>>>> I think one thing has been written in this thread that is worth
>>>>> noting and could be an intermediate position.
>>>>> 
>>>>> It seems to me one place where we could get some useful information,
>>>>> and provide it to users is for iterative algorithms (both optimizers
>>>>> and solvers have already been mentioned, we could add ode integrators
>>>>> as well to this). For such algorithms, having some way to monitor how
>>>>> the iterations perform seem an improvement. An observer pattern as
>>>>> proposed a few days ago for this kind of algorithms would be fine.
>>>>> Once again, something simple and that does not attempt to be hyper
>>>>> generic but rather taylored to the algorithms (i.e. most probably
>>>>> different observer interfaces for different algorithms types).
>>>>> 
>>>>> This intermediate position would provide something to both users
>>>>> and developers, and it would not attempt to log everything and
>>>>> add a dependency (I am probably the one who opposed to logging on
>>>>> the grounds of dependencies).
>>>>> 
>>>>> best regards,
>>>>> Luc
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Gilles
>>>>>> 
>>>>>>>> 
>>>>>>>> Thomas
>>>>>>>> 
>>>>>>>>>>>>> My long-standing mentioning of slf4j
was only because of its
>>>>>>>>>>>>> "weightlessness" (thanks to the no-op
implementation of its
>> API).
>>>>>>>>>>>>> If "Log4j 2" has followed this path,
good for everyone.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> No objection, then?
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm still not clear what log4j 2 adds --
most Apache java
>> projects
>>>>>>>>>>>> seem to
>>>>>>>>>>>> use log4j 1.2, seems to work well. -- H
>>>>>>>>>>>> 
>>>>>>>>>>> I can only answer about "slf4j" where the "f"
stands for facade:
>> it's
>>>>>>>>>>> "only"
>>>>>>>>>>> an API, with bridges to several logging frameworks
(log4j,
>> logback,
>>>>>>>>>>> etc.).
>>>>>>>>>>> 
>>>>>>>>>>> The separation of concerns (API vs one of several
>> implementations to
>>>>>>>>>>> choose from)
>>>>>>>>>>> allows the top-level application to uniformly
configure logging
>> or to
>>>>>>>>>>> disable it
>>>>>>>>>>> completely (if choosing the "no-op" implementation).
>>>>>>>>>> That is virtually true for all logging frameworks,
including
>> log4j,
>>>>>>>>>> slf4j, commons-logging.
>>>>>>>>> Has it always been true?
>>>>>>>>> I'm certainly no expert; I only try to stay clear of
tools about
>> which
>>>>>>>>> people complain a lot.  A few years ago, that was the
case of jcl
>> and
>>>>>>>>> jul as compared to slf4j.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Gilles
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>> 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 <mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message