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://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 >
