To be devil's advocate, you can filter your log file according to both level and marker, right?
On Fri, Jan 24, 2014 at 4: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<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 > -- Cheers, Paul
