Paul, can you give a bit more detail? I tried this: copy the current Level enum to a new enum called "Levels" in the same package (other name would be fine too). Then change Level to an interface (removing the constants and static methods, keeping only the non-static methods). Finally make the Levels enum implement the Level interface.
After this, we need to do a find+replace for the references to Level.CONSTANT to Levels.CONSTANT and Level.staticMethod() to Levels.staticMethod(). Finally, the interesting part: how do users add or register their custom levels and how do we enable the Levels.staticLookupMethod(String, Level) to recognize these custom levels? On Thursday, January 23, 2014, Paul Benedict <pbened...@apache.org> wrote: > Agreed. This is not an engineering per se, but really more about if the > feature set makes sense. > > Well if you guys ever look into the interface idea, you'll give log4j the > feature of getting enums to represent custom levels. That's pretty cool, > IMO. I don't know if any other logging framework has that and that would > probably get some positive attention. It shouldn't be so hard to do a > find+replace on the code that accepts Level and replace it with another > name. Yes, there will be some minor refactoring that goes with it, but > hard? It shouldn't be. > > A name I propose for the interface is LevelDefinition. > > Paul > > > On Wed, Jan 22, 2014 at 6:48 PM, Gary Gregory <garydgreg...@gmail.com>wrote: > > Hi, I do not see this as an engineering problem but more a feature set > definition issue. So while there may be lots of more or less internally > complicated ways of solving this with interfaces, makers and whatnots, the > built in levels are the most user friendly. > > I have have lots of buttons, knobs and settings on my sound system that I > do not use, just like I do not use all the methods in all the classes in > the JRE... > > Gary > > > -------- Original message -------- > From: Remko Popma > Date:01/22/2014 18:38 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Web Issues, Logging Levels, and GA > > 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: > > -- > Cheers, > Paul >
