Maybe:
ZOMBIE_APOCALYPSE > APOCALYPSE > CATASTROPHE > EMERGENCY > FATAL > ...
On 23 Jan 2014, at 3:56, Gary Gregory wrote:
But that is not as high as APOCALYPSE right?
Gary
-------- Original message --------
From: Matt Sicker <boa...@gmail.com>
Date:01/22/2014 21:43 (GMT-05:00)
To: Log4J Developers List <log4j-dev@logging.apache.org>
Subject: Re: Web Issues, Logging Levels, and GA
I think we should use the CATASTROPHE logging level.
On 22 January 2014 17:38, Remko Popma <remko.po...@gmail.com> wrote:
Looks like we're in a tricky spot...
I count four people in favor of keeping the current levels who don't
want to add levels (Paul, Christian, Matt and myself),
two people who really want to add levels (Gary and Nick)
and two people who are not pushing for new levels but don't mind the
change (Scott and Ralph).
I don't think of adding new levels as a compromise, as it would only
satisfy a few of us.
Can we try finding a way that would satisfy all parties?
Why don't we think a little more about finding some mechanism that
allows users to add custom levels that are *as easy or nearly as easy
to use as the pre-defined levels*?
That mechanism can be anything (markers, extensible enum, an
interface, something else?), I am open to ideas.
This is an engineering problem, let's use our engineering skills
(instead of our debate skills :-).)
Let's think about this more, with open minds, before rushing into a
solution that many have reservations about.
On Thu, Jan 23, 2014 at 6:07 AM, Paul Benedict <pbened...@apache.org>
wrote:
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
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
--
Cheers,
Paul
--
Cheers,
Paul
--
Matt Sicker <boa...@gmail.com>
---
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
