I think the 'levels=severity' model broke down a bit when we added TRACE, and FATAL is never used, so I think it's reasonable to say there isn't a strict severity we can use even today - which is why we have so few levels (trying to stick to the severity model).
By the way, we should remove FATAL, yes? Scott On 1/24/14, Paul Benedict <pbened...@apache.org> wrote: > I agree. When anyone starts talking about "types" of informational messages > or "types" of debug information, those should be distinguished with > markers. > > My mental model is this: > levels = severity > markers = kinds/types > > > > On Fri, Jan 24, 2014 at 1:57 PM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> I would tend to agree with the way you are using them. >> >> I do see a a need for DIAG (or whatever other name you like). We don’t >> tend to use a lot of info messages as those are just nice to know things >> but probably wouldn’t aid a lot in problem diagnosis. OTOH, DEBUG tends >> to >> log everything except method entry and exit. This is typically much more >> than what operators or users need to determine what might have caused a >> problem. INFO could be used for this but I’m not sure that the name >> “Informational” lends itself to people thinking it will contain messages >> to >> aid in problem diagnosis. The only issue I see with adding a DIAG level >> is >> getting programmers to actually use it properly - but I don’t think that >> is >> our problem. >> >> I do agree with the notion that logging configuration or initialization >> is >> important, but as I’ve stated I think the best way to do that is with >> Markers. The same technique that was mentioned previously about creating >> specific loggers for that is easy to do with Markers - see EventLogger >> for >> an example. >> >> Ralph >> >> >> On Jan 24, 2014, at 11:39 AM, Paul Benedict <pbened...@apache.org> wrote: >> >> 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 >> <grobme...@gmail.com>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 <remko.po...@gmail.com> 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 >>>>> <garydgreg...@gmail.com>wrote: >>>>> >>>>> On Thu, Jan 23, 2014 at 10:18 PM, Ralph Goers >>>>>> <ralph.go...@dslextreme.com>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 <remko.po...@gmail.com> >>>>>>> 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 <remko.po...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> I'm fine with Nick's proposal to have two separate votes. >>>>>>>> Remko >>>>>>>> >>>>>>>> On Friday, January 24, 2014, Nick Williams < >>>>>>>> nicho...@nicholaswilliams.net> 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 >>>>>>>>> <scott.de...@gmail.com>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 <pbened...@apache.org> 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: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> 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: log4j-dev-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>> >>> >>> >>> --- >>> http://www.grobmeier.de >>> The Zen Programmer: http://bit.ly/12lC6DL >>> @grobmeier >>> GPG: 0xA5CC90DB >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> >>> >> >> >> -- >> Cheers, >> Paul >> >> >> > > > -- > Cheers, > Paul > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
