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 21:36:27 GMT
I use trace for wire level hex dumps. Think Wireshark.

Gary

-------- Original message --------
From: Christian Grobmeier <grobmeier@gmail.com> 
Date:01/22/2014  15:12  (GMT-05:00) 
To: Log4J Developers List <log4j-dev@logging.apache.org> 
Subject: Re: Web Issues, Logging Levels, and GA 

Jumping in late, sorry. I have read all messages around this now 
(hopefully) and I am still unsure why we actually need new log levels.
Personally I don't see much difference between trace and verbose. 
Honestly the people I spoke to are usually using debug. I don't know 
many people who actually use trace. If you need trace, you often need a 
debugger... having a second level called verbose would at least confuse 
me.

I find DIAG interesting. Before a while I thought how one would log 
METRICS which I believe might be the closest match to DIAG. On the other 
hand when would you like to disable metrics/diag? Mertrics shouldn't be 
disabled at all to my understanding and when it comes to deeper 
diagnosis I wonder if it would make more sense to have an appender which 
"buffers" all statements until he receives on of a specific level like 
error. Then he should print everything. Thats more a diagnostic tool 
which makes sense to me. I can do that with existing log levels and 
markers, but maybe it would make sense to have some DIAG.

However I don't see where DIAG does fit in the hierarchy. For me its a 
different beast then the usual log levels. I can imagine situations when 
I want to see diagnostics on ERROR level quickly. Sometimes they are so 
expensive i want them on debug level. I would prefer to tell log4j 
diagnostic on/off instead of putting it into a hierarchy.

I also see no reason to include NOTICE. If the systems sends me 
something i need to read its a warn.

My 2 cents



On 22 Jan 2014, at 15:59, Ralph Goers wrote:

> I am fine with DIAG.  I had always thought INFO was the abbreviation 
> for INFORMATIONAL, which is way too long.
>
> Ralph
>
>> On Jan 22, 2014, at 6:21 AM, Gary Gregory <garydgregory@gmail.com> 
>> wrote:
>>
>>> 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
>>>>>> JUnit in Action, Second Edition
>>>>>> Spring Batch in Action
>>>>>> 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
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory


---
http://www.grobmeier.de
The Zen Programmer: http://bit.ly/12lC6DL
@grobmeier
GPG: 0xA5CC90DB

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Mime
View raw message