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
