commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <...@spaceroots.org>
Subject Re: [Math] Utilitzation of SLF4J?
Date Sat, 26 Sep 2015 20:09:35 GMT
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
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message