As Gary wanted, a new thread....
First, each enum needs an inherit strength. This would be part of the
interface. Forgive me if the word "strength" is wrong; but it's the 100,
200, 300, etc. number that triggers the log level. So make sure the
interface contains the intLevel() method.
Second, we need to know the name, right? The name probably requires a new
method since it can't be extracted from the enum anymore.
public interface Level {
int intLevel();
String name();
}
PS: The intStrength() name seems hackish. What about strength() or
treshold()?
Third, the registration can be done manually by providing a static method
(as your did Remko) that the client needs to invoke, or you could have a
class-path scanning mechanism. For the latter, you could introduce a new
annotation to be placed on the enum class.
@CustomLevels
public enum MyCustomEnums {
}
Paul
On Wed, Jan 22, 2014 at 8:52 PM, Remko Popma <remko.po...@gmail.com> wrote:
> 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
>>
>>
