I use trace for wire level hex dumps. Think Wireshark.
Gary
-------- Original message --------
From: Christian Grobmeier <grobme...@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 <garydgreg...@gmail.com>
>> wrote:
>>
>>> On Wed, Jan 22, 2014 at 1: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.
>>
>> 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 <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
>>>>>> 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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
