This is how I use today's levels: TRACE - entry and exit of methods, raw and extremely detailed data dumps DEBUG - status and configuration to view while application is running for developer inspection purposes INFO - application state changes that an operator may need to know to inspect health of program WARN - failure/exception that can be recovered (alternate choice of action does exist) ERROR - failure/exception that can't be recovered from (the normal case) FATAL - failure/exception that is known to render the application unusable
Paul On Fri, Jan 24, 2014 at 1:20 PM, Christian Grobmeier <[email protected]>wrote: > What I miss in this discussion are actually good examples of what the > (new) log levels are intended for. > > In example, Gary mentioned he is on a wireshark level with "trace". > That's fine, because it would give some idea when to use verbose (maybe > entering method). > > Maybe I missed it when what I ask for was already written, > but I believe if we can give concrete example how log levels should be > used then we are a step further. > > I was asked quite a log what should be logged with which level. > > I think making the difference between trace and debug is already difficult > for a lot of users. > In the past two years i asked a lot of people how they log. > > The answer was: exceptions on error, the rest on debug. > > What we lack is a good recommendation how log levels should be used. > Something which is on our front page and which lets the "average" Java > programmer fully > understand when he uses what, and maybe even why. > > If we have something like that it is much easier to argue pro/contra > the new log levels. > > > > > > > On 24 Jan 2014, at 18:36, Scott Deboy wrote: > > To be fair, I think we represent a reasonable fraction of the >> users..some won't touch new predefined levels, some will use it - >> that's the reason for adding it - we hit a significant portion of use >> cases with small additional number of built-in levels. >> >> The two solutions don't provide the same thing, do they? If they do, >> I wouldn't be pressing the issue. >> >> If there is a way for us, via annotations or whatever mechanism we >> define for 'custom levels', to add support easily for the newly >> pre-defined levels, then we should do it. >> >> Specifically, I'm ok with any mechanism (even using the new custom >> level mechanism, but provide by log4j itself), where log4j users are >> able to call: >> >> logger.notice(something); >> >> Anything else and it won't meet my expectations for usability. >> >> By the way, while we're at it, let's remove fatal. >> >> Scott >> >> >> On 1/24/14, Remko Popma <[email protected]> wrote: >> >>> I'm not questioning your experience, and I believe you when you say that >>> the proposed levels would be a perfect match for your current work >>> environment. >>> >>> However, out of the eight people that participated in the discussion on >>> adding levels, four expressed strong reservations about adding >>> pre-defined >>> levels. We are all programmers on this list. So I think we can reasonable >>> assume that a large fraction of users would also not like this change. >>> >>> On top of that, we have a more powerful and elegant alternative solution >>> that makes adding pre-defined levels unnecessary. >>> Sorry, but I veto the commit. >>> >>> >>> >>> >>> On Sat, Jan 25, 2014 at 1:49 AM, Gary Gregory >>> <[email protected]>wrote: >>> >>> On Thu, Jan 23, 2014 at 10:18 PM, Ralph Goers >>>> <[email protected]>wrote: >>>> >>>> Gary, although Remko hasn’t said it I think he is implying that he is >>>>> vetoing the code commit. Unfortunately, unless you can convince Remko >>>>> otherwise you are going to have to revert the commit. >>>>> >>>>> Remko, if that isn’t your intention then please say so as it will save >>>>> Gary a bunch of work. >>>>> >>>>> >>>> Hello, hello, >>>> >>>> Wow, what a pickle of religious debate this has turned into! >>>> >>>> Before I do indeed do more work: >>>> >>>> >>>> >>>>> >>>>> >>>> Ralph >>>>> >>>>> On Jan 23, 2014, at 6:34 PM, Remko Popma <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>> I wish you had a story of some kind to show why you are so strongly >>>> opposed to the new levels. I just wonder then why you are not arguing >>>> for >>>> fewer levels? Is 6 levels just the perfect number in your mind? If you >>>> designed a new logging system right now in a clean room approach, what >>>> would you devise? >>>> >>>> FWIW, I do consider Log4j2 a brand new system, granting us the freedom >>>> to >>>> break APIs with version 1, which we've obviously done, but not in a way >>>> that will make it too difficult to port client code. For custom >>>> appenders, >>>> I've not tried to port my version 1 appenders yet... >>>> >>>> >>>> To clarify my position on the proposed DIAG, VERBOSE, NOTICE log >>>>> levels: >>>>> I don't think these levels should be added to the Log4J API. >>>>> Here is my thinking: >>>>> >>>>> 1. The current five levels are a de facto. standard. (For example, they >>>>> match the SLF4J levels.) >>>>> >>>>> But they do not match JUL, which is more of a standard since it is in >>>>> the >>>>> >>>> JRE; albeit a _brain-dead_ standard; no DEBUG level JUL? Really? >>>> So clearly we care about certain kinds of standard but not others. >>>> Since the Slf4j author created Log4j1, I would not expect otherwise and >>>> it >>>> should not make it the best solution moving forward by default. >>>> >>>> >>>> They are sufficient for the vast majority of log4j users. We should be >>>>> hesitant to change this. My position would be to not change this unless >>>>> we >>>>> all think this is a really good idea. (The bar should be high for this >>>>> change.) >>>>> >>>>> What are you afraid of? Confusing developers and users with 3 new >>>>> levels? >>>>> >>>> Let's give them more credit than that! ;) >>>> >>>> >>>> 2. From a practical point of view, making. levels an Extensible Enum >>>>> provides a more powerful alternative solution, making the proposed >>>>> levels >>>>> unnecessary. >>>>> 3. From an engineering/aestical POV, I feel the proposed levels are >>>>> arbitrary and the Extensible Enum solution is more elegant. >>>>> >>>>> >>>>> AGAIN, there are different features, why are they mutually exclusive? >>>> >>>> >>>> 4. The proposed levels are not only unnecessary, I think they are >>>>> actually detrimental (for lack of a better word. I mean, not having >>>>> them >>>>> would be better). >>>>> The discussion in the "Web Issues, Logging Levels, and GA" thread >>>>> shows >>>>> how much opinions can differ about naming, strength, and intended >>>>> usage, >>>>> *even in our small group*. How can we predict what levels other users >>>>> may >>>>> want? >>>>> >>>>> >>>>> How about using your own experience as a guideline? How have the >>>> current >>>> levels confused your users? Would fewer levels been better for them? >>>> >>>> I've creating a logging system before Log4j1 existed, ported our server >>>> to >>>> Log4j1 and then extended Log4j1 for our servers and tools at work. >>>> Believe >>>> you me, if I've taken the time to write the code, I will use it in our >>>> apps >>>> instead of the inconsistent various workarounds that have propagated in >>>> our >>>> code base. These are not "oh, these would be nice to have in theory", >>>> theses are "I know I can change my code now to use the new levels". >>>> Granted, I am an advanced user. But like any system, I started using a >>>> few >>>> features and then more and more. >>>> >>>> We do use TRACE for some method entry and exit. And we use DEBUG a lot. >>>> But we need a level, among other things, for wire level hex dumps in all >>>> the different parts of the systems where many loggers are used. A level >>>> between TRACE and DEBUG would be a perfect solution. I and others have >>>> made >>>> a good case for the NOTICE level as well, which some wanted as CONFIG. >>>> >>>> I see the new levels as a refinement based on experience. >>>> >>>> Is this now a religious debate in which there is 0 chance of convincing >>>> you? Or is there 1 chance? >>>> >>>> >>>> The proposed levels can easily confuse users or get in the way of users >>>>> wanting to use these names at different strengths or with a different >>>>> intended usage. >>>>> >>>>> >>>>> Whaaat? How can you presume to know users like that? Give people more >>>> credit than that, we are talking about programmers here. For our end >>>> users, >>>> our support folks tell them "Set the level to X and run the program, >>>> then >>>> send us the log" where they use a GUI to generate log config files. Our >>>> consultants (some are programmers) that go onsite, know the software and >>>> what the levels mean. They and the users will be ecstatic if I say that >>>> the >>>> giant logs given by DEBUG will be smaller because all the hex dumps will >>>> be >>>> at the VERBOSE levels. The TRACE level is for developers debugging very >>>> low >>>> level code. FWIW, we had started to use different loggers for hex dumps >>>> but >>>> this was hard to enforce and harder to configure, so no more of that. >>>> >>>> So before I revert anything please answer these questions and try to >>>> convince _me_ :) >>>> >>>> Alternatively, feel free to reply with "I VETO this commit" and will >>>> revert the commit. >>>> >>>> Thank you kindly for considering these opinions, >>>> >>>> Gary >>>> >>>> >>>> >>>>> The fact that changes for these levels have already been committed is >>>>> IMHO not an argument in its favor. On the contrary, I was surprised at >>>>> the >>>>> timing of this commit: it was clear that many people were opposed to >>>>> this >>>>> approach. To me it was also clear that we had started exploring >>>>> extensible >>>>> enums as a mechanism that would allow us to *avoid* adding pre-defined >>>>> levels. >>>>> >>>>> >>>>> To repeat my position: I don't think these levels should be added to >>>>> the >>>>> Log4J API. >>>>> >>>>> Remko >>>>> >>>>> On Friday, January 24, 2014, Remko Popma <[email protected]> >>>>> wrote: >>>>> >>>>> I'm fine with Nick's proposal to have two separate votes. >>>>>> Remko >>>>>> >>>>>> On Friday, January 24, 2014, Nick Williams < >>>>>> [email protected]> wrote: >>>>>> >>>>>> There has obviously been some serious discussion about these topics. >>>>>>> We're not going to come to a total agreement on this. I propose: >>>>>>> >>>>>>> - We have a committers-only vote in the "Enums and Custom Levels" >>>>>>> thread on whether to make Level an extensible enum. >>>>>>> - AFTER having that vote, we have a committers-only vote in this >>>>>>> thread >>>>>>> on whether to add these three levels. >>>>>>> - We only roll back this revision AFTER the second vote is complete >>>>>>> and >>>>>>> IF the vote rejects the new levels. >>>>>>> >>>>>>> Nick >>>>>>> >>>>>>> On Jan 23, 2014, at 7:58 AM, Paul Benedict wrote: >>>>>>> >>>>>>> On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>> We don't need to scuttle the new levels to support extensible >>>>>>>> levels. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Of course. The two things are not technically related. That's not >>>>>>> what >>>>>>> this is about, though. Since there are camps for and against the new >>>>>>> levels, I was hoping the "extensible enum" feature would bring about >>>>>>> a >>>>>>> compromise. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Gary's change is essentially a 'usability enhancement' - if anything >>>>>>>> close to 80% of the folks who might want custom levels can use new >>>>>>>> built-in levels, that's an API win in my book. Custom levels help >>>>>>>> the >>>>>>>> other 20%, and I'm supportive of that. >>>>>>>> >>>>>>>> Also please keep in mind this doesn't really add to our maintenance >>>>>>>> burden, which I think may be contributing to the concern about >>>>>>>> adding >>>>>>>> new levels. Gary already did the heavy lifting, and the change to >>>>>>>> something other than an enum for levels would just be a bit more >>>>>>>> work >>>>>>>> because of this addition. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> On 1/23/14, Paul Benedict <[email protected]> wrote: >>>>>>>> >>>>>>>>> Let's not lose sight why the "extensible enum" discussion occurred. >>>>>>>>> Speaking solely for myself, I am not fond of the new logging >>>>>>>>> levels; >>>>>>>>> >>>>>>>> but I >>>>>>>> >>>>>>>>> don't want the framework from preventing them. The intention behind >>>>>>>>> >>>>>>>> this >>>>>>>> >>>>>>>>> proposal was to get agreement by scuttling the new levels but >>>>>>>>> >>>>>>>> allowing >>>>>>>> >>>>>>>>> anyone to add them in their own private code. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> Java Persistence with Hibernate, Second >>>> Edition<http://www.manning.com/bauer3/> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>> Spring Batch in Action <http://www.manning.com/templier/> >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>>> >>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --- > http://www.grobmeier.de > The Zen Programmer: http://bit.ly/12lC6DL > @grobmeier > GPG: 0xA5CC90DB > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Paul
