One thing I find interesting in this discussion is that Unix systems have been dealing with syslog levels for years. (See http://www.ypass.net/blog/2012/06/introduction-to-syslog-log-levelspriorities/) for a nice discussion on them. Of the 8 levels 3 essentially map to what we call “FATAL” (2 of those 3 applications should never use). Syslog has NOTICE exactly where Gary placed it so reusing that doesn’t strike as something that people would find confusing. OTOH, syslog doesn’t even have the TRACE level.
As for Diagnostic vs debug - I thought I made that clear when I suggested the name. Diagnostic messages are what Operations and/or end users might find of interest when errors (or warnings) happen. They are not the error or warning messages themselves but provide more detailed information to aid in problem solving. They would be messages that could be helpful without having to resort to looking at the code. Debug messages are usually of more interest to developers and typically include information on the internal workings of the system. I tend to agree that there is ambiguity between TRACE and VERBOSE, but I have no problem adding it if it means end users will have more flexibility with little cost. Whatever we do it needs to be done now before a GA release. The Levels are all defined with integer values that will have to change if new levels are inserted thus breaking compatibility (everything using Log4j 2 in the system will need to be recompiled). In hindsight it probably would have been better to multiply the values by 100. Ralph On Jan 21, 2014, at 7:17 AM, Paul Benedict <[email protected]> wrote: > Gary, with respect, I disagree with that philosophy. Because logging levels > have an inherit order (fatalistic --> tracing), it's really important for the > names to match the intended gradation. The levels make total sense with the 5 > we have. For example, I know FATAL > ERROR > WARN > INFO just because the > English language has it as such. I also know DEBUG > TRACE. However, the new > ones, there's no such easy match. I *will* have to look them up to figure out > where they are on the scale ... and, I also don't like where they're being > placed. > > * Diagnostic is really no better than debug. I can't make up an argument why > I that's superior over debug(). > * Trace is pretty much verbose -- so why be verbose without tracing? Or why > isn't your debug verbose? > > I don't agree necessarily disagree with the intention of adding more; I just > don't think log4j can accurately label them or give them good meaning. This > should be left to individual developers through an expansion mechanism. > > > > On Tue, Jan 21, 2014 at 8:27 AM, Gary Gregory <[email protected]> wrote: > On Mon, Jan 20, 2014 at 11:06 PM, Paul Benedict <[email protected]> wrote: > That's up to you guys :-) As I said, I don't think the extra logging levels > have any real true definition to where they belong. It can be argued until > the end of time where they fit. But since you definitely want more, just copy > what's already out there so at least you can say you're consistent with > someone else's answer. > > I'm thinking now that it does not matter so much what the levels are called > (within reason) but that there are enough of them so give developers enough > granularity. > > Gary > > > On Mon, Jan 20, 2014 at 9:48 PM, Gary Gregory <[email protected]> wrote: > On Mon, Jan 20, 2014 at 10:40 PM, Paul Benedict <[email protected]> wrote: > If you really want extra logging levels without the long debate, just go copy > the logging levels of Apache HTTPD. They already figured out where to place > all the extra levels you guys are discussing and they've been around for > years. It will be a worthy precedent to copy. > > > That would be 16 levels then? > https://httpd.apache.org/docs/2.4/mod/core.html#loglevel > > Gary > > On Jan 20, 2014 9:09 PM, "Gary Gregory" <[email protected]> wrote: > On Mon, Jan 20, 2014 at 9:54 PM, Paul Benedict <[email protected]> wrote: > I know we had the debate of extra logging levels for the past year. The extra > levels are very subjective. If anyone needs more than our standard five, > please just use markers. We should even have a whole page on the site > dedicated to such a solution. > > It really is impossible to get consensus on the subject. I never needed more > then our standard levels and every proposal for more shows the confusion that > no one is really clear where they belong. > > > I think that with Ralphs list, we are getting a nice solution/evolution. > > The great thing about the new levels is that no one is forcing developers to > use the new levels, feel free to ignore them! ;) > > As a user, it is very easy to throttle how much log events you get, change > "DEBUG" to "VERBOSE" and you're done. > > OTOH, achieving the same effect with makers is more work IMO for developers > and users. So I look at markers as the workaround to the 'levels are not fine > enough for my app' problem. Saying "use markers" is not a fair comparison to > "change the level", from a dev and user POV. Yes, it's a solution but a much > heavier one. > > Gary > > On Jan 18, 2014 2:27 PM, "Gary Gregory" <[email protected]> wrote: > On Sat, Jan 18, 2014 at 2:35 PM, Nicholas Williams > <[email protected]> wrote: > To be clear, here's how I see it (assuming we adopted all levels proposed): > > FATAL > ERROR > WARN > CONFIG > INFO > VERBOSE > DEBUG > FINE > TRACE. > > Interesting, I would have swapped CONFIG and INFO. > > Can you talk a little more why CONFIG > INFO (and not INFO > CONFIG)? For > me, I would use VERBOSE for configuration logging. > > Gary > > > > CONFIG would map to INFO for slf4j. VERBOSE and FINE would both map to DEBUG. > > My motivation for FINE was similar to your motivation for VERBOSE: DEBUG > isn't quite enough. In retrospect, I agree more with you that something is > needed more on the INFO side of DEBUG rather than the TRACE side. That would > allow DEBUG to be used for what it's really meant for. So I'm fine with > VERBOSE instead. > > My reason for putting CONFIG between INFO and WARN is simple: I ALWAYS want > to see config-related messages when the application starts, but I don't > always want to see INFO messages after it starts. And if something > re-configures while the application is running, I want to see that, too. I've > developed the habit of logging startup messages as WARNings, which I don't > like doing. > > Hope that helps some. > > Nick > > Sent from my iPhone from the Las Vegas airport, so please forgive brief > replies and frequent typos > > On Jan 18, 2014, at 11:21, Ralph Goers <[email protected]> wrote: > >> STEP? No clue what that means. >> >> Gary, if you want to implement VERBOSE between INFO and DEBUG I’m OK with >> that, but what will that map to in SLF4J, etc. DEBUG? >> >> And yes, something on the web site should document our recommended usage for >> levels and markers. >> >> Ralph >> >> >> On Jan 18, 2014, at 10:53 AM, Gary Gregory <[email protected]> wrote: >> >>> Ah, my view of VERBOSE is that it is _more_ information, hence INFO < >>> VERBOSE < DEBUG; while it sounds like Ralphs sees it as more DEBUG data. >>> >>> For me DEBUG data is going to be already verbose, even more than 'verbose'. >>> >>> What is interesting (to me) is that DEBUG is often misused based on this >>> basic mix: debug messages can be for users *and/or* for developers, there >>> is no distinction in the audience. >>> >>> For example, as a user, I want to get data to help me debug my >>> configuration and my process. As a developer, I want to debug the code. >>> These can be two very different set of data. >>> >>> But we do not have DEBUG_USER and DEBUG_DEV levels. I would see INFO next >>> to VERBOSE as useful to users. Then DEBUG and TRACE useful for developers. >>> Each app can have its convention of course, but it would be nice to have >>> the distinction available through levels for developers to use. >>> >>> I see TRACE as method entry and exit type of logging, *very* *low* level >>> stuff. >>> >>> We could also have both (ducking for projectiles): >>> >>> INFO >>> VERBOSE >>> DEBUG >>> STEP >>> TRACE >>> >>> Gary >>> >>> >>> On Sat, Jan 18, 2014 at 12:47 PM, Ralph Goers <[email protected]> >>> wrote: >>> Oops. I just noticed you proposed that VERBOSE be between INFO and DEBUG. >>> Now that I don’t understand. My experience is that VERBOSE is usually more >>> detailed than debug messages, not less. >>> >>> Ralph >>> >>> On Jan 18, 2014, at 9:44 AM, Ralph Goers <[email protected]> wrote: >>> >>>> I understand the need for CONFIG. However it isn’t clear to me whether it >>>> belongs between INFO and WARN or DEBUG and INFO. That is because it >>>> typically would be used to log configuration during startup. That doesn’t >>>> necessarily imply that you would then want to see all INFO messages as >>>> well. Due to that, it would make more sense to me to make a CONFIG marker. >>>> >>>> I don’t really understand the point of FINE or FINER. >>>> >>>> On the other hand, VERBOSE does make a bit more sense, but I’m struggling >>>> with how that is any different than TRACE. I guess the idea is that TRACE >>>> is for control flow (entry, exit) and VERBOSE is for more detailed debug >>>> messages? I suppose I can go along with that argument, but again one >>>> could just as easily create a VERBOSE marker and attach it to either TRACE >>>> or DEBUG. I guess I wouldn’t object if VERBOSE was added as a Level but >>>> I’m not really convinced it is necessary either. >>>> >>>> Ralph >>>> >>>> >>>> >>>> On Jan 18, 2014, at 7:08 AM, Remko Popma <[email protected]> wrote: >>>> >>>>> I've always liked Ralph's argument that Markers give users much more >>>>> flexibility than any predefined Levels. >>>>> I would prefer to stick to the log4j/slf4j level names. >>>>> >>>>> >>>>> On Sat, Jan 18, 2014 at 10:32 PM, Gary Gregory <[email protected]> >>>>> wrote: >>>>> Interesting, I have been wanting a VERBOSE level better INFO and DEBUG. >>>>> >>>>> See >>>>> http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201310.mbox/%3CCACZkXPxNwYbn__CbXUqFhC7e3Q=kee94j+udhe8+6jiubcz...@mail.gmail.com%3E >>>>> >>>>> You'll have to dig a little in that ref to find my proposal, sorry I'm on >>>>> my phone ATM. >>>>> >>>>> It sounds like we see logging configuration messages differently though. >>>>> I do not like the name CONFIG because it does not sound like a level to >>>>> me. Otoh, many command lines have a verbose AND a debug switch. So it >>>>> makes sense to me too have corresponding levels. >>>>> >>>>> Gary >>>>> >>>>> >>>>> -------- Original message -------- >>>>> From: Nick Williams >>>>> Date:01/17/2014 23:50 (GMT-05:00) >>>>> To: Log4J Developers List >>>>> Subject: Web Issues, Logging Levels, and GA >>>>> >>>>> Wanted to update y'all. As you know, I've been very absent lately due to >>>>> the book consuming every minute of my free time. I know I haven't been >>>>> contributing my due, and for that please accept my sincerest apologies. >>>>> The book is finally done (goes on sale next month!) and I can get back to >>>>> regular life. I'm going to be out of town for the next week on a >>>>> much-needed vacation with very limited access to email. I'll be back the >>>>> weekend of January 25-26, and that weekend I will be spending almost the >>>>> entire time finally dealing with the 8-10 web application-related bugs. >>>>> After that, I don't see any encumbrances to releasing 2.0.0.GA. >>>>> >>>>> Except... >>>>> >>>>> Logging Levels. We kinda-sorta talked about this a few months ago, and a >>>>> few months before that, and a few months before that, but we never >>>>> actually DID anything about it. It's clear by now that my "extendable >>>>> enum" proposal (that would be a drop-in replacement for and binary >>>>> compatible with the current Level enum) is not going to be accepted. >>>>> Absent any other proposals, I suggest we add the following new levels >>>>> before GA: >>>>> >>>>> CONFIG - Between INFO and WARN, mapped to INFO for bridges to other >>>>> frameworks that don't have an equivalent level >>>>> >>>>> FINE - Between DEBUG and TRACE, mapped to TRACE for bridges to other >>>>> frameworks that don't have an equivalent level >>>>> >>>>> I'll let y'all chat about that over the next week. ;-) >>>>> >>>>> Be back soon, >>>>> >>>>> Nick >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>> >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > -- > Cheers, > Paul > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > -- > Cheers, > Paul
