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<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
