A ZOMBIE_APOCALYPSE Level would be EPIC! ;-)
N
On Jan 23, 2014, at 1:31 AM, Christian Grobmeier wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
