On Fri, Jan 24, 2014 at 12:15 PM, 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. > ACK. Revert committed. Gary > > > > > 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 >> > > -- 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
