logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Web Issues, Logging Levels, and GA
Date Wed, 22 Jan 2014 14:21:39 GMT
On Wed, Jan 22, 2014 at 1:33 AM, Ralph Goers <ralph.goers@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.
>
>

>

I am in agreement with Ralph.

I created LOG4J-508 (new levels) and LOG4J-507 (space level ints by 100) to
track this for the release notes. SVN has the new levels in now.

Before the new Logger methods roll in I thought we could finalize our
choice of the DIAG level name. The names NOTICE and VERBOSE feel pretty
good to me and are 'standard' in the sense that other systems and command
lines make use of the terms (as mentioned elsewhere in the thread).

Right now, we have DIAG in SVN which could also be DIAGNOSTIC. DIAGNOSTIC
would be our longest name; we do have precedent for abbreviation: we have
WARN instead of WARNING. There is also DIAGNOSIS. Using DIAG would get devs
choose the variant in conversation. We could of course not abbreviate
anything and rename WARN to WARNING or INFO to INFORM for example, making
all the levels either verbs or nouns, but not a mix.

Gary


> Ralph
>
>
> On Jan 21, 2014, at 8:50 AM, Paul Benedict <pbenedict@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 <pbenedict@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 <garydgregory@gmail.com>wrote:
>>
>>> On Tue, Jan 21, 2014 at 11:33 AM, Paul Benedict <pbenedict@apache.org>wrote:
>>>
>>>> On Tue, Jan 21, 2014 at 10:25 AM, Ralph Goers <
>>>> ralph.goers@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: garydgregory@gmail.com | ggregory@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
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
View raw message