Not to rehash this issue, but I wanted to clarify what can be vetoed, for future reference.
I'm only bringing this up to make it clear, unless there is a 'technical justification', a veto is invalid. In my opinion, there was no 'technical justification' for requesting removal of the new levels, just a preference (since the technical solution for providing the levels was already in place). http://www.apache.org/foundation/glossary.html#Veto ...Vetos may not be overridden nor voted down, and only cease to apply when the committer who issued the veto withdraws it. All vetos must be accompanied by a valid technical justification; a veto without such a justification is invalid; in case of doubt, deciding whether a technical justification is valid is up to the PMC.... Scott On 1/25/14, Gary Gregory <garydgreg...@gmail.com> wrote: > On Sat, Jan 25, 2014 at 5:10 AM, Christian Grobmeier > <grobme...@gmail.com>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 <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 >>>> >>> >> >> --- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
