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://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
