Scott, the disagreement is in purpose. There are those who believe the new
logging levels are finely-tuned additions that have their proper place in
the level hierarchy; others do not. The debate would be no different if the
levels truly were CATASTROPHE and APOCALYPSE. I am making a silly analogy,
of course, but I hope it makes the point to you. It's all about where to
draw the line in the sand.
On Thu, Jan 23, 2014 at 4:23 PM, Scott Deboy <scott.de...@gmail.com> wrote:
> I understand folks may not 'prefer' to have the additional levels, but
> if it won't cause us a maintenance burden (it won't), and it it's
> already in place (it is) and it provides a simple mechanism for a
> majority of the 'custom level' needs (very likely), there really isn't
> much of a disagreement is there?
>
> As I mentioned, other than statements of preference, I don't see what
> technical reasons there would be for not wanting to provide this
> simple mechanism to our end users.
>
> If you want to vote, first let's have a 'discuss' thread where we
> explain why folks are against something that's already implemented -
> hopefully due to technical reasons, and not just personal preference.
>
> Scott
>
> On 1/23/14, Remko Popma <remko.po...@gmail.com> wrote:
> > Scott, with all respect, I disagree.
> >
> > True, WRT extensible enum (this thread) I haven't seen anyone opposing
> this
> > idea. We're still fine-tuning the implementation but I haven't seen
> anyone
> > arguing against this. I don't mind making sure of that with a vote
> though.
> >
> > However, WRT the new levels (the other thread) I am not confident that we
> > can reach consensus.
> >
> > If we follow the Apache process, the first vote will be open for 72 hours
> > (correct me if I'm wrong) anyway. That should give everyone enough time
> to
> > explain their position on the new levels before we start the second
> vote.
> > Who knows, perhaps we're all in agreement by that time...
> >
> >
> > On Friday, January 24, 2014, Scott Deboy <scott.de...@gmail.com> wrote:
> >
> >> I don't think we need a vote on the new level code..there's no good
> >> technical reason to ask it to be removed, and it is likely to be
> >> useful to some group of folks.
> >>
> >> I think we're doing a good job on the other thread bouncing ideas of
> >> how to handle extensible levels, and that conversation should continue
> >> on that thread until we reach consensus, which I'm sure we will be
> >> able to do.
> >>
> >> Scott
> >>
> >> On 1/23/14, Remko Popma <remko.po...@gmail.com> wrote:
> >> > I'm fine with Nick's proposal to have two separate votes.
> >> > Remko
> >> >
> >> > On Friday, January 24, 2014, Nick Williams <
> >> nicho...@nicholaswilliams.net>
> >> > wrote:
> >> >
> >> >> By a generic definition, this new Level is certainly an enum. And
> it's
> >> >> written in Java. No, it's not a Java-language official enum. But, as
> >> >> far
> >> >> as
> >> >> byte code goes, it's nearly identical to an official enum. Users who
> >> >> don't
> >> >> need custom levels will use it EXACTLY like they would use an enum.
> >> >> It's
> >> >> an
> >> >> improvement over a traditional enum only in that you can extend it. I
> >> see
> >> >> no downsides at all.
> >> >>
> >> >> There has obviously been some serious discussion about these topics.
> >> >> We're
> >> >> not going to come to a total agreement on this. I propose:
> >> >>
> >> >> - We have a committers-only vote in this thread on whether to make
> >> >> Level
> >> >> an extensible enum.
> >> >> - AFTER having that vote, we have a committers-only vote in the
> >> >> "Levels
> >> >> added in revision 1560602" thread on whether to add the three levels
> >> that
> >> >> were added.
> >> >> - We only roll back 1560602 AFTER the second vote is complete and IF
> >> >> the
> >> >> vote rejects the new levels.
> >> >>
> >> >> Nick
> >> >>
> >> >> On Jan 23, 2014, at 6:23 AM, Ralph Goers wrote:
> >> >>
> >> >> I’m more in favor of this than what you had proposed. To be honest,
> >> >> with
> >> >> what you proposed I don’t see much value left in keeping the Level
> >> >> enum.
> >> >>
> >> >> Yes, I prefer using the enum (obviously, or I wouldn’t have
> >> >> implemented
> >> >> it
> >> >> that way), but if the consensus is to change it to a class, so be it.
> >> >>
> >> >> As for comments on the below, I think it needs a bit of tweaking (I
> >> >> wouldn’t use Hashtable) but it may be a better option than adding
> more
> >> >> levels. Or we could add the extra levels but not add new methods for
> >> >> them
> >> >> to AbstractLogger.
> >> >>
> >> >> Ralph
> >> >>
> >> >> On Jan 23, 2014, at 7:49 AM, Paul Benedict <pbened...@apache.org>
> >> wrote:
> >> >>
> >> >> It's a neat idea but it's not a Java enum. I think one of Ralph's
> goal
> >> >> was
> >> >> to allow client code to use enums. I still think we should continue
> >> >> that
> >> >> path. At any rate, this will hopefully lead to a synthesis of ideas
> >> >> and
> >> >> agreement.
> >> >>
> >> >>
> >> >> On Thu, Jan 23, 2014 at 8:22 AM, Matt Sicker <boa...@gmail.com>
> wrote:
> >> >>
> >> >> Neat idea. I'd update it for proper concurrency, though. I could
> write
> >> >> a
> >> >> mock version of this to show what I mean.
> >> >>
> >> >> Matt Sicker
> >> >>
> >> >> > On Jan 23, 2014, at 2:42, Nick Williams <
> >> nicho...@nicholaswilliams.net>
> >> >> wrote:
> >> >> >
> >> >> > Okay, I finally got a minute to read all of these emails, and...
> >> >> >
> >> >> > EVERYBODY FREEZE!
> >> >> >
> >> >> > What if I could get you an extensible enum that required no
> >> >> > interface
> >> >> changes and no binary-incompatible changes at all? Sound too good to
> >> >> be
> >> >> true? I proposed this months ago (LOG4J2-41) and it got shot down
> >> >> multiple
> >> >> times, but as of now I've heard THREE people say "extensible enum" in
> >> >> this
> >> >> thread, so here it is, an extensible enum:
> >> >> >
> >> >> > public abstract class Level implements Comparable<Level>,
> >> >> > Serializable
> >> >> > {
> >> >> > public static final Level OFF;
> >> >> > public static final Level FATAL;
> >> >> > public static final Level ERROR;
> >> >> > public static final Level WARN;
> >> >> > public static final Level INFO;
> >> >> > public static final Level DEBUG;
> >> >> > public static final Level TRACE;
> >> >> > public static final Level ALL;
> >> >> >
> >> >> >
> >> >> > private static final long serialVersionUID = 0L;
> >> >> >
> >>
> pri---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> log4j-dev-unsubscr...@logging.apache.org<javascript:;>
> >> For additional commands, e-mail:
> >> log4j-dev-h...@logging.apache.org<javascript:;>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>
--
Cheers,
Paul
