You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Jacob Dall <jd...@eurisco.dk> on 2013/03/22 11:24:37 UTC
Yet another custom log levels posting
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Yet another custom log levels posting
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 26, 2013 at 12:01 AM, Paul Benedict <pb...@apache.org>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
>
Interesting, 8 levels instead of our 6. I can see that as 'better' in the
sense that it would allow the finer logging Jacob mentions.
But what about the current version of HTTPD, it has even MORE levels, 16!
https://httpd.apache.org/docs/2.4/mod/core.html#loglevel
How about that?!
Gary
>
> 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 <ga...@gmail.com>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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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
>>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: Yet another custom log levels posting
Posted by Paul Benedict <pb...@apache.org>.
After looking through the issue and contemplating your response, I believe
an "extensible enum" solution is not the way to go. I don't think we should
depart from Java 5 enums. Log4j provides standard levels for logging and
they don't need any extension. What we really need is the ability to people
to pass in some token, backed by some strategy, that evaluates the token to
determine when to log. I prefer my approach as previously stated.
On Mon, Mar 25, 2013 at 11:20 PM, Nick Williams <
nicholas@nicholaswilliams.net> wrote:
> Forgiven. On LOG4J2-41 I made a comment in which I put the code for an
> extensible enum. An "extensible enum," in this case, is an enum written the
> way they USED to be written, before Java added enum support. In this case
> it is written to exactly match the standard enum API (and even
> serialize/deserialize essentially the same way), so that's why it's API
> compatible. But since it's actually an abstract class and not an enum
> (which is what the compiler turns enums into anyway), it's extensible.
>
> If you go look at that issue [1], you'll see the code for it in my
> comment, as well as a one-line-of-code example of how to extend it.
>
> The ONLY thing I really change was I made the level intLevels multiples of
> 100, so that custom levels can easily be "inserted" in between. This may
> cause some existing tests to fail, but that will be easily fixed.
>
> In retrospect, all of the methods in my example should be final. I
> neglected to do that.
>
> [1] https://issues.apache.org/jira/browse/LOG4J2-41
>
>
> On Mar 25, 2013, at 11:09 PM, Paul Benedict wrote:
>
> 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 <
> nicholas@nicholaswilliams.net> 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 <ga...@gmail.com>
>> 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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
>> > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > 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: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
Re: Yet another custom log levels posting
Posted by Nick Williams <ni...@nicholaswilliams.net>.
Forgiven. On LOG4J2-41 I made a comment in which I put the code for an extensible enum. An "extensible enum," in this case, is an enum written the way they USED to be written, before Java added enum support. In this case it is written to exactly match the standard enum API (and even serialize/deserialize essentially the same way), so that's why it's API compatible. But since it's actually an abstract class and not an enum (which is what the compiler turns enums into anyway), it's extensible.
If you go look at that issue [1], you'll see the code for it in my comment, as well as a one-line-of-code example of how to extend it.
The ONLY thing I really change was I made the level intLevels multiples of 100, so that custom levels can easily be "inserted" in between. This may cause some existing tests to fail, but that will be easily fixed.
In retrospect, all of the methods in my example should be final. I neglected to do that.
[1] https://issues.apache.org/jira/browse/LOG4J2-41
On Mar 25, 2013, at 11:09 PM, Paul Benedict wrote:
> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> 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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Yet another custom log levels posting
Posted by Paul Benedict <pb...@apache.org>.
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 <
nicholas@nicholaswilliams.net> 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 <ga...@gmail.com>
> 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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Yet another custom log levels posting
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ga...@gmail.com> 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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Yet another custom log levels posting
Posted by Paul Benedict <pb...@apache.org>.
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 <ga...@gmail.com>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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
>
Re: Yet another custom log levels posting
Posted by Gary Gregory <ga...@gmail.com>.
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 <jd...@eurisco.dk> 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: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
RE: Yet another custom log levels posting
Posted by Jacob Dall <jd...@eurisco.dk>.
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Yet another custom log levels posting
Posted by Ralph Goers <ra...@dslextreme.com>.
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org