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.
I agree with your other usages. Ralph On Jan 24, 2014, at 2:22 PM, Gary Gregory <garydgreg...@gmail.com> 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 <grobme...@gmail.com> > 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 <garydgreg...@gmail.com>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 <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 > > > --- > 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 > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > 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
