Yes yes now we are getting somwhere... UNICORN_AND_RAINBOWS!
G
-------- Original message --------
From: Christian Grobmeier <grobme...@gmail.com>
Date:01/23/2014 06:31 (GMT-05:00)
To: Log4J Developers List <log4j-dev@logging.apache.org>
Subject: Re: Web Issues, Logging Levels, and GA
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
