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
