I think we should use the CATASTROPHE logging level.
On 22 January 2014 17:38, Remko Popma <remko.po...@gmail.com> wrote:
> Looks like we're in a tricky spot...
>
> I count four people in favor of keeping the current levels who don't want
> to add levels (Paul, Christian, Matt and myself),
> two people who really want to add levels (Gary and Nick)
> and two people who are not pushing for new levels but don't mind the
> change (Scott and Ralph).
>
> I don't think of adding new levels as a compromise, as it would only
> satisfy a few of us.
>
> Can we try finding a way that would satisfy all parties?
> Why don't we think a little more about finding some mechanism that allows
> users to add custom levels that are *as easy or nearly as easy to use as
> the pre-defined levels*?
>
> That mechanism can be anything (markers, extensible enum, an interface,
> something else?), I am open to ideas.
> This is an engineering problem, let's use our engineering skills (instead
> of our debate skills :-).)
>
> Let's think about this more, with open minds, before rushing into a
> solution that many have reservations about.
>
>
>
> On Thu, Jan 23, 2014 at 6:07 AM, Paul Benedict <pbened...@apache.org>wrote:
>
>> Yes, I know. It is a big change but it is also one that's necessary to
>> support custom logging levels that are enums.
>>
>>
>> On Wed, Jan 22, 2014 at 3:04 PM, Ralph Goers
>> <ralph.go...@dslextreme.com>wrote:
>>
>>> Paul,
>>>
>>> Take a look at the Logger, LoggerConfig and Lo4jLogEvent classes and
>>> LogEvent interface in log4j-core. Then look at the Filter interface and
>>> the ThresholdFilter implementation. Looking at those classes you will see
>>> that the change you are proposing has a much larger impact than what you
>>> are thinking. Since the custom levels would not be part of the enum all
>>> the code would have to be changed to use the new Interface you are
>>> proposing, not the Level enum.
>>>
>>> Ralph
>>>
>>>
>>> On Jan 22, 2014, at 12:37 PM, Paul Benedict <pbened...@apache.org>
>>> wrote:
>>>
>>> Ralph,
>>>
>>> Perhaps you're misunderstanding or I was unclear (let's say it's the
>>> latter).
>>>
>>> The interface is only so you can allow custom log levels as an enum. The
>>> client code could still use the enums you provided today. All that's
>>> changing is the API signatures to accept the interface -- which
>>> conveniently all the enums would implement. As I said,
>>> FATAL/ERROR/INFO/WARN/DEBUG/TRACE would implement the interface.
>>>
>>> It's worth considering this because I think we're about to pollute log4j
>>> with logging levels that really don't belong in the public api. These are
>>> definitely custom things people should implement themselves.
>>>
>>> Paul
>>>
>>>
>>> On Wed, Jan 22, 2014 at 12:33 AM, Ralph Goers <
>>> ralph.go...@dslextreme.com> wrote:
>>>
>>>> First, I assume you meant to code “implements LogLevelStrength” instead
>>>> of “extends LogLevelStrength” since an enum already implicitly extends Enum
>>>> and a Class (or Enum) can’t extend an Interface.
>>>>
>>>> Second, doing this would mean that the Log4j 2 core would have to be
>>>> modified to never use the Level enum and only use the Interface, except
>>>> perhaps in ThresholdFilter which can really only be configured with one of
>>>> the Level enum values. Not being able to use Level as a method parameter
>>>> and field in the LogEvent makes its value as an enum minimal. Only being
>>>> able to use Level values in the ThresholdFilter means anyone with a custom
>>>> Level has to write their own custom Level Filter.
>>>>
>>>> I think providing the extra levels is a fair compromise.
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Jan 21, 2014, at 8:50 AM, Paul Benedict <pbened...@apache.org>
>>>> wrote:
>>>>
>>>> Or if you really want to get fancy (!!!), don't make the log4j API
>>>> accept an Level, but an interface that each logging level Enum object
>>>> implements. Then programmers can use enums. Example:
>>>>
>>>>
>>>> public interface LogLevelStrength {
>>>> int getStrength();
>>>> }
>>>>
>>>> public enum Level extends LogLevelStrength {
>>>> FATAL() {
>>>> public int getStrength() { return 600; }
>>>> }
>>>> ...
>>>> }
>>>>
>>>> public enum MyCustomLevel extends LogLevelStrength {
>>>> DIAGNOSTIC() {
>>>> public int getStrength() { return 250; }
>>>> }
>>>> ...
>>>> }
>>>>
>>>>
>>>>
>>>> On Tue, Jan 21, 2014 at 10:45 AM, Paul Benedict
>>>> <pbened...@apache.org>wrote:
>>>>
>>>>> It won't be possible with an enum, yes, but we should have a way to
>>>>> allow extensions. For example, if we publically document the integer level
>>>>> of the enums (separated by 100), then we can provide an overload that
>>>>> accepts an integer. That's how you can allow people to slide in their
>>>>> extensions. Philospohy: enums for the standard, ints for the custom
>>>>> programmer.
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> On Tue, Jan 21, 2014 at 10:42 AM, Gary Gregory <garydgreg...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> On Tue, Jan 21, 2014 at 11:33 AM, Paul Benedict <pbened...@apache.org
>>>>>> > wrote:
>>>>>>
>>>>>>> On Tue, Jan 21, 2014 at 10:25 AM, Ralph Goers <
>>>>>>> ralph.go...@dslextreme.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I tend to agree that there is ambiguity between TRACE and VERBOSE,
>>>>>>>> but I have no problem adding it if it means end users will have more
>>>>>>>> flexibility with little cost.
>>>>>>>>
>>>>>>>>
>>>>>>> I think this is meaningless flexibility. It smells of adding a
>>>>>>> feature without a good reason. Imagine the conversations people will
>>>>>>> have
>>>>>>> to explain the difference between TRACE and VERBOSE. I can't think of
>>>>>>> any
>>>>>>> good universal justification for its use that demands an addition to
>>>>>>> log4j.
>>>>>>>
>>>>>>
>>>>>> If you do not like it, do not use it ;)
>>>>>>
>>>>>> This is best reserved for a personal extension.
>>>>>>>
>>>>>>
>>>>>> Which is not possible since Level is an enum, hence this discussion
>>>>>> before the API freezes.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Paul
>>
>
>
--
Matt Sicker <boa...@gmail.com>
