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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> > I'm fine with Nick's proposal to have two separate votes. >> > Remko >> > >> > On Friday, January 24, 2014, Nick Williams < >> [email protected]> >> > 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 <[email protected]> >> 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 <[email protected]> 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 < >> [email protected]> >> >> 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: >> [email protected]<javascript:;> >> For additional commands, e-mail: >> [email protected]<javascript:;> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
