Nick, you'll have to forgive me not following the whole thread too closely, but what is an "extensible enum"? Enums are not extensible in Java.
Paul On Mon, Mar 25, 2013 at 11:07 PM, Nick Williams < [email protected]> wrote: > By the way, the recommendation of mine that he seconded in LOG4J2-41 > (creating an extensible enum) would be auto-pluggable. The developer would > provide the custom strategy merely by extending Level and instantiating a > singleton instance of his class at startup. That maintains the safety of > enums, doesn't change the API, and also satisfies the "I want a custom > level" crowd. > > My $0.02. > > Nick > > On Mar 25, 2013, at 11:01 PM, Paul Benedict wrote: > > > If any more standard levels are to be added, I would use Apache HTTPD as > inspiration: > > http://httpd.apache.org/docs/2.2/mod/core.html#loglevel > > > > However, I think there is a way to perhaps satisfy the "I want a custom > level" crowd by giving them an option to pass a string name for their > custom logging level. They also would have to provide a custom strategy at > configuration time to recognize the custom level and process it accordingly. > > > > Example: > > log.logCustomLevel(String, ....); > > > > I don't know what example to show for a pluggable strategy. But I hope > you get my drift. > > > > Paul > > > > On Mon, Mar 25, 2013 at 10:57 PM, Gary Gregory <[email protected]> > wrote: > > Interesting stuff. > > > > So it looks like you want one more level than L4J2 provides: > > > > ALL > > FATAL > > ERROR > > WARN > > INFO > > DEBUG > > TRACE > > > > I've often wanted to have a level between INFO and DEBUG, like: > > > > INFO > > NOTE > > DEBUG > > > > which is different than what you want ;) > > > > I can see that having a level between INFO and WARN would be useful but > we are really slicing it thin... > > > > I've also wondered about having a level called EXIT above FATAL, but the > use for it would be only to log events just before a System.exit(): > > > > ALL > > EXIT > > FATAL > > ... > > > > If you were to map the current Log4J levels to your semantics (aside > from the missing level), you could customize the level names in the log4j > config. > > > > Gary > > > > > > On Mon, Mar 25, 2013 at 9:09 AM, Jacob Dall <[email protected]> wrote: > > For many years we've been using the following definition of log levels > (invented by someone else but us) > > > > ALWAYS: event always logged > > FATAL: severe error event presumable leading to an abort > > CRIT: event that might still allow processing > > ERROR: potentially harmful event > > WARN: event that might lead to errors later on > > NOTICE: normal but significant event > > INFO: informational event > > DEBUG: debug-level messages > > > > I cannot justify these levels per say, besides that fact that we have a > need for more error-like levels than what's available per default. Being > forced to no longer use these would be an true issue in our software > development. > > I not sure that Log4j 2 shall support these natively, though it would be > nice ;) > > But I need the feature that allows me to add these and use them like > real log levels. > > > > If Enum's does not do the trick, simply use something else. I agree that > it should be something defined, though - not just an Int. > > I fully second Nick's idea (LOG4J2-41 : > https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612306#comment-13612306) > using an abstract class. > > > > About custom levels not having a named level method... that something > easy to live with (we've lived with it for 15+ years). It should not be a > reason for making it impossible to define custom levels. > > > > Thanks > > Jacob > > > > -----Original Message----- > > This needs to be an FAQ. > > > > Log levels are defined as enums. Unfortunately, Java enums cannot be > extended. > > > > In addition, at the moment the API only allows you to call methods like > debug, error, etc. Although we might add log methods that accept a level, > we will never add methods with names of levels that don't exist. This means > if you create your own custom levels then your users will either need a > custom API or have to use the log method, assuming it is added. At the > moment they would have no way to use the custom level. > > > > FWIW, if you can justify why an additional log level should be added > that would certainly be considered. > > > > Ralph > > > > > > On Mar 22, 2013, at 3:24 AM, Jacob Dall wrote: > > > > > Dear "Log4j 2" developers. > > > > > > From all the postings on the internet concerning custom log levels > with "Log4j 2" it is obvious that this shall be accomplished by using the > Markers feature. > > > > > > Unfortunately this only solves half of the problem, because this does > not make it possible to set the log level on a logger to one besides the > predefined ones. > > > > > > So if one, for instance, defines a custom level NOTICE to be located > between INFO and WARN, one can log an event with level NOTICE, but cannot > set a logger to only log NOTICE and above - one has to set the level to > INFO to capture NOTICE level messages, which does the trick, but is not > exactly right. > > > > > > I like the new features in "Log4j 2", but in this particular area I > believe it has missed the train. > > > > > > Would someone be so kind as to enlighten me on the reasoning behind > making it impossible for programmers to extend the log levels like it was > possible in "Log4j 1"? > > > > > > > > > Kind regards > > > Jacob Dall > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > E-Mail: [email protected] | [email protected] > > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > > Spring Batch in Action: http://bit.ly/bqpbCK > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
