This is only a problem for webapps, right? Putting log4j jars in WEB-INF/lib avoids that problem (different class loader). Apps that really want to share log4j jars with other apps would need to play nice. Such apps would do well to use a naming convention like Gary suggests. Otherwise, the last to register would overwrite any previous level with the same name. (Should probably emit a StatusLogger warning.)
Same intLevel for different names should not be a problem. On Thursday, January 23, 2014, Gary Gregory <[email protected]> wrote: > Playing devils advocate: > > What happens when different apps register levels with the same name and > different intLevels? > What happens when different apps register levels with the same intLevel > and different names? > Should there be a convention that custom level names be FQNs? > > Gary > > > On Wed, Jan 22, 2014 at 10:05 PM, Paul Benedict > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > wrote: > >> 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 >> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> >> > 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 >>> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>> >>> 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 >>>> <[email protected]>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 >>>> >>>> >> > > > -- > E-Mail: [email protected] <javascript:_e({}, 'cvml', > '[email protected]');> | [email protected] <javascript:_e({}, > 'cvml', '[email protected]');> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory >
