On Sat, Jan 25, 2014 at 5:10 AM, Christian Grobmeier <[email protected]>wrote:
> Thanks a lot Gary for the great response. Now I understand you better. Thank you Christian. I created the branch https://svn.apache.org/repos/asf/logging/log4j/log4j2/branches/new-levelsfor those who want to a have easy look. Gary > > On 25 Jan 2014, at 2:00, Ralph Goers wrote: > >> I have the same problem with your use of NOTICE as I did with CONFIG. If >> I want to see startup and shutdown log events I MUST also get warning >> messages, which isn’t necessarily what I want. For startup, shutdown & >> configuration Markers should be used. That doesn’t mean I probably >> couldn’t come up with a separate use case for the level though. >> > > In the end we might be able to solve everything using markers. Log levels > are some kind of convenient methods for me (ok, a little more). > We need to keep balance between them. > > I think DIAG might be really useful. At the moment I use Markers with > DEBUG to emulate DIAG. > > NOTICE: > Using Markers might require more discipline by our users than using > logger.notice(); > Like: logger.debug(CONNECTIVITY, ""); > > If the NOTICE recommendation would be to write everything related to > connectivity on this level it it would make much sense to me. > > In example: > - Java app connects to MQSeries with version $x. > - Java app lost connection to database, but reconnects. > - Java initiates call to the Paypal API successfully (but the actual > communication is logged on debug / diag) > > That said, I am moving towards +1 for this change. > > > >> I agree with your other usages. >> >> Ralph >> >> On Jan 24, 2014, at 2:22 PM, Gary Gregory <[email protected]> wrote: >> >> Here is my usage: >>> >>> FATAL - Logged from main(String[]) methods when a checked exception is >>> caught, also for unchecked exceptions in main(String[]) like >>> IllegalArgumentException. You need to know if it is appropriate for your >>> main(String[]) method to even throw an exception; if your class is never >>> called from another Java app, then catch all exceptions and log them in >>> main(String[]). Also consider using this pattern for methods that behave >>> like main(String[]), for example in a Quartz job's execute method. Use >>> before calling System.exit(int) with an error value (usually not 0). >>> >>> ERROR - Exceptions that the program cannot recover. For example: the app >>> cannot connect to a database, so data cannot be read or written. A request >>> needs to be re-submitted. >>> >>> WARN - Exceptions that the program can recover from. For example: a >>> configuration file cannot be found, so some defaults kick in. If your app >>> uses configuration by exception, then this level is not appropriate, use >>> NOTICE instead. >>> >>> NOTICE (now I use INFO) - The app start up and shutdown banners. The >>> kind of information "mvn -version" and "java -version" return. "The server >>> is starting", "The server started", "The server is shutting down", "The >>> server is down, goodbye.". This should be the level for production system. >>> >>> INFO - Describes what the application is doing, not too chatty. Useful >>> for ops to tell the server is actually up and running, this is high-level >>> heartbeat kind of data. So things like "Processing request foo", "Processed >>> request bar". This should be the level on QA systems. >>> >>> DIAG (now DEBUG) - What a user may need to fix problems. In a business >>> process app (workflow, we have a BPM app), there are the steps in the >>> workflow (like high level transactions: account debited for user foo, >>> accout credited, call logged with support, technician SMS sent, and so >>> on.). This should be the level on development systems. >>> >>> DEBUG - What a developer needs to debug. Connecting to database for >>> example. This is the bulk for debug data. >>> >>> VERBOSE (now DEBUG) - Hex dumps for wire-level communications. Contents >>> of buffers going in and out of memory, in and out of files. When XSL >>> transformations take place, log the input, the XSL being called, then the >>> output. >>> >>> TRACE - method entry and method exit, nothing else. >>> >>> As you can see the DEBUG level is overloaded. >>> >>> This is the biggest problem. User debug info and internal product debug >>> info are MIXED. Our users are confused, our consultants don't like the >>> giant logs. >>> >>> Gary >>> >>> >>> On Fri, Jan 24, 2014 at 3:56 PM, Christian Grobmeier < >>> [email protected]> wrote: >>> On 24 Jan 2014, at 21:47, Paul Benedict wrote: >>> >>> We should ensure that both the Javadocs and the user guide explain >>> recommended usages for these. Mailing lists are for the most die-hard >>> development fans. :-) >>> >>> +1 >>> >>> Recommendations and documentation are/is absolutely necessary. >>> >>> I will happily go through the mailing list to look how you use the >>> various log levels. >>> But you also should know that I have read a ton of mails on this topic >>> the past >>> two days and I am still unsure how *you* use the log levels. I am still >>> stuck with my own usage, >>> and that is in my opinion the point why we can't reach an agreement >>> easily. >>> >>> >>> >>> >>> >>> On Fri, Jan 24, 2014 at 2:38 PM, Gary Gregory <[email protected] >>> >wrote: >>> >>> There have been descriptions of what the levels are for... see Ralph ' >>> message, many of mine and others. I know it can be tedious to go back >>> through various threads but the info is there. If you want more info, >>> feel >>> free to ask ;) >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: Christian Grobmeier >>> Date:01/24/2014 14:20 (GMT-05:00) >>> To: Log4J Developers List >>> Subject: Re: Levels added in revision 1560602 >>> >>> 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 >>> >>> >>> --- >>> 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] >>> >>> >>> >>> >>> -- >>> 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 >>> >> > > --- > 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] > > -- 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
