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]
