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.) 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.) 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. 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? 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. 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 <[email protected]> wrote: > I'm fine with Nick's proposal to have two separate votes. > Remko > > On Friday, January 24, 2014, Nick Williams > <[email protected]<javascript:_e({}, 'cvml', > '[email protected]');>> > 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 <[email protected]>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 <[email protected]> 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 >> >> >>
