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