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 Xen <xe...@dds.nl> on 2015/08/27 16:36:01 UTC
The Range of Levels
By the way,
I know that regularly and naturally when you write your own debugging
verbosity code you always use levels of 0 = no logging (or most
important), 1 = a little more verbose, and so on. So 0 might amount to
FATAL and 3 might amount to INFO. But I get the distinct impression from
dealing with and perhaps using also log4j that it is the other way around.
I get the impression, I don't know what from, that TRACE is actually
"lowest" and FATAL is actually "highest". In the code,
"isMoreSpecificThat" obviously deviates from and obviates the need to talk
in high and low, since DEBUG is obviously more specific (if you think
about it even two seconds) than INFO.
Rather, I still have this impression that TRACE is "low" probably also
because in the docs (pdf manual) they are located as such in the tables;
it starts with TRACE and ends with FATAl (from left to right or top to
bottom).
Was this an intended consequence?. It seems also right to call FATAL
"higher". A threshold also seems to indicate a "level that needs to be
surpassed". Such that INFO is naturally "below" FATAL because FATAL goes
"above" the threshold dictated for INFO. This is why it seems so natural
for me to think this way. I also have never dealt with the numeric values
directly.
Was this intended?.
Regards, Bart.
On Thu, 27 Aug 2015, Xen wrote:
> Seems pretty obvious to me, if you want my opinion.
>
> I'm not in love with the name, but I don't know what else.
>
> fallsWithin(level, level)
>
> maybe just
>
> isInRangeOf although very verbose, the other two methods are equally verbose.
> I think it would match. Personally I would choose either isInRangeOf or
> (perhaps ugly) fallsWithin.
>
> Cause if you're using verbs for method names you do so for legibility and
> natural-language-ness. It might just look well to keep that intact from
> /isLessSpecificThan/ to /isInRangeOf/.
>
> if (L.isInRangeOf(Level.DEBUG, Level.TRACE) --< oops does it work if the one
> is higher than the other, or the other way around?. I think the code should
> swap depending on condition, but I haven't looked at the code yet.
> ) {
> doSomethingElseEntirely();
> }
>
> ;-).
>
> Regards.
>
>
> On Wed, 26 Aug 2015, Gary Gregory wrote:
>
>> Hi All,
>>
>> To make it easier to implement a LevelRangeFilter (patch with test here:
>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>> Level)
>>
>> This seems like right place which since we already have:
>>
>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>
>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the patch
>> (with tests).
>>
>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>
>> OK, not OK?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: The Range of Levels
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Aug 31, 2015 at 6:02 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> If I didn't already tell you to go ahead I meant to.
>
Done; in Git master.
Gary
>
> Ralph
>
> On Aug 31, 2015, at 4:15 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> A reminder that I am looking for a go ahead to commit or feedback on the
> following:
>
>
>>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>>
>>> Hi All,
>>>>
>>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a
>>>> new
>>>> method to the public API:
>>>> org.apache.logging.log4j.Level.isInRange(Level,
>>>> Level)
>>>>
>>>> This seems like right place which since we already have:
>>>>
>>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>>>
>>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the
>>>> patch
>>>> (with tests).
>>>>
>>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>>>
>>>> OK, not OK?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: The Range of Levels
Posted by Ralph Goers <ra...@dslextreme.com>.
If I didn't already tell you to go ahead I meant to.
Ralph
> On Aug 31, 2015, at 4:15 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> A reminder that I am looking for a go ahead to commit or feedback on the following:
>
>>>
>>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>>
>>>> Hi All,
>>>>
>>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>>>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>>>> Level)
>>>>
>>>> This seems like right place which since we already have:
>>>>
>>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>>>
>>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the patch
>>>> (with tests).
>>>>
>>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>>>
>>>> OK, not OK?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>
>
Re: The Range of Levels
Posted by Gary Gregory <ga...@gmail.com>.
A reminder that I am looking for a go ahead to commit or feedback on the
following:
>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>
>> Hi All,
>>>
>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>>> Level)
>>>
>>> This seems like right place which since we already have:
>>>
>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>>
>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the
>>> patch
>>> (with tests).
>>>
>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>>
>>> OK, not OK?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
Re: The Range of Levels
Posted by Gary Gregory <ga...@gmail.com>.
I wonder why we picked 100 instead of 1000 ;-)
"No one will need more than 640k of memory"
http://www.computerworld.com/article/2534312/operating-systems/the--640k--quote-won-t-go-away----but-did-gates-really-say-it-.html
G
On Thu, Aug 27, 2015 at 9:07 AM, Remko Popma <re...@gmail.com> wrote:
> Bart, the log4j2 int levels are based on the log4j 1 levels (multiplied by
> 100 to allow custom levels in between).
> So this is historical, rather than anything else.
>
> Remko
>
> Sent from my iPhone
>
> > On 2015/08/27, at 23:36, Xen <xe...@dds.nl> wrote:
> >
> > By the way,
> >
> > I know that regularly and naturally when you write your own debugging
> verbosity code you always use levels of 0 = no logging (or most important),
> 1 = a little more verbose, and so on. So 0 might amount to FATAL and 3
> might amount to INFO. But I get the distinct impression from dealing with
> and perhaps using also log4j that it is the other way around.
> >
> > I get the impression, I don't know what from, that TRACE is actually
> "lowest" and FATAL is actually "highest". In the code, "isMoreSpecificThat"
> obviously deviates from and obviates the need to talk in high and low,
> since DEBUG is obviously more specific (if you think about it even two
> seconds) than INFO.
> >
> > Rather, I still have this impression that TRACE is "low" probably also
> because in the docs (pdf manual) they are located as such in the tables; it
> starts with TRACE and ends with FATAl (from left to right or top to bottom).
> >
> > Was this an intended consequence?. It seems also right to call FATAL
> "higher". A threshold also seems to indicate a "level that needs to be
> surpassed". Such that INFO is naturally "below" FATAL because FATAL goes
> "above" the threshold dictated for INFO. This is why it seems so natural
> for me to think this way. I also have never dealt with the numeric values
> directly.
> >
> > Was this intended?.
> >
> > Regards, Bart.
> >
> >
> >
> >
> >
> >> On Thu, 27 Aug 2015, Xen wrote:
> >>
> >> Seems pretty obvious to me, if you want my opinion.
> >>
> >> I'm not in love with the name, but I don't know what else.
> >>
> >> fallsWithin(level, level)
> >>
> >> maybe just
> >>
> >> isInRangeOf although very verbose, the other two methods are equally
> verbose. I think it would match. Personally I would choose either
> isInRangeOf or (perhaps ugly) fallsWithin.
> >>
> >> Cause if you're using verbs for method names you do so for legibility
> and natural-language-ness. It might just look well to keep that intact from
> /isLessSpecificThan/ to /isInRangeOf/.
> >>
> >> if (L.isInRangeOf(Level.DEBUG, Level.TRACE) --< oops does it work if
> the one is higher than the other, or the other way around?. I think the
> code should swap depending on condition, but I haven't looked at the code
> yet.
> >> ) {
> >> doSomethingElseEntirely();
> >> }
> >>
> >> ;-).
> >>
> >> Regards.
> >>
> >>
> >>> On Wed, 26 Aug 2015, Gary Gregory wrote:
> >>>
> >>> Hi All,
> >>> To make it easier to implement a LevelRangeFilter (patch with test
> here:
> >>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a
> new
> >>> method to the public API:
> org.apache.logging.log4j.Level.isInRange(Level,
> >>> Level)
> >>> This seems like right place which since we already have:
> >>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
> >>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
> >>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the
> patch
> >>> (with tests).
> >>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
> >>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
> >>> OK, not OK?
> >>> Gary
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> Java Persistence with Hibernate, Second Edition
> >>> <http://www.manning.com/bauer3/>
> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >>> Spring Batch in Action <http://www.manning.com/templier/>
> >>> 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
> >
> > ---------------------------------------------------------------------
> > 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
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: The Range of Levels
Posted by Xen <xe...@dds.nl>.
I have no issue with the numbers, I don't even know the numbers.
Maybe I should just go and find out since you don't tell me....
Ah, so indeed DEBUG is 1 (or 10000) and FATAL is 5 (or 50000).
Hmmm so that means my impression was correct and congruent with the
explanations in the tutorials.
I don't mind it, I think it's fine.
It's more commonsensical in terms of thresholds and if you write your
own old-style debug verbosity levels you always have to twist your mind
in a weird direction to understand how to do the right comparison ;-).
I usually do it wrong the first time :P. Exactly in reverse of what it
needs to be :P.
if (messageVerbosity <= debugLevel) {
print it
}
or maybe you should say
if (debugLevel >= messageVerbosity) { }
It remains weird. I think it is better this way.
On 08/28/2015 02:51 PM, Ralph Goers wrote:
> I had the same reaction when I first started looking at levels. In log4j1 it was worse since levels were ints, the value was always in your face. With enums it isn't quite as obvious. It is also why we renamed the level method that does the checking to something like "isLessSpecific" so the numeric value wouldn't show through.
>
> As far as the numbers go, I had to just get over it. I suggest you do the same.
>
> Sent from my iPad
>
>> On Aug 28, 2015, at 5:07 AM, Xen <xe...@dds.nl> wrote:
>>
>> But that still doesn't make me understand because I don't know anything about those log4j 1 levels ;-).
>>
>> I was not criticising. I don't even know the numeric value of those levels at this point.
>>
>> It's just that, supposing FATAL has a low value, and TRACE has a high value (???)
>>
>> then how come I think of FATAL as high and TRACE as low? Or is it the other way around?.
>>
>> :P.
>>
>> Regards..
>>
>>
>>> On 08/27/2015 06:07 PM, Remko Popma wrote:
>>> Bart, the log4j2 int levels are based on the log4j 1 levels (multiplied by 100 to allow custom levels in between).
>>> So this is historical, rather than anything else.
>>>
>>> Remko
>>>
>>> Sent from my iPhone
>>>
>>>> On 2015/08/27, at 23:36, Xen <xe...@dds.nl> wrote:
>>>>
>>>> By the way,
>>>>
>>>> I know that regularly and naturally when you write your own debugging verbosity code you always use levels of 0 = no logging (or most important), 1 = a little more verbose, and so on. So 0 might amount to FATAL and 3 might amount to INFO. But I get the distinct impression from dealing with and perhaps using also log4j that it is the other way around.
>>>>
>>>> I get the impression, I don't know what from, that TRACE is actually "lowest" and FATAL is actually "highest". In the code, "isMoreSpecificThat" obviously deviates from and obviates the need to talk in high and low, since DEBUG is obviously more specific (if you think about it even two seconds) than INFO.
>>>>
>>>> Rather, I still have this impression that TRACE is "low" probably also because in the docs (pdf manual) they are located as such in the tables; it starts with TRACE and ends with FATAl (from left to right or top to bottom).
>>>>
>>>> Was this an intended consequence?. It seems also right to call FATAL "higher". A threshold also seems to indicate a "level that needs to be surpassed". Such that INFO is naturally "below" FATAL because FATAL goes "above" the threshold dictated for INFO. This is why it seems so natural for me to think this way. I also have never dealt with the numeric values directly.
>>>>
>>>> Was this intended?.
>>>>
>>>> Regards, Bart.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Thu, 27 Aug 2015, Xen wrote:
>>>>>
>>>>> Seems pretty obvious to me, if you want my opinion.
>>>>>
>>>>> I'm not in love with the name, but I don't know what else.
>>>>>
>>>>> fallsWithin(level, level)
>>>>>
>>>>> maybe just
>>>>>
>>>>> isInRangeOf although very verbose, the other two methods are equally verbose. I think it would match. Personally I would choose either isInRangeOf or (perhaps ugly) fallsWithin.
>>>>>
>>>>> Cause if you're using verbs for method names you do so for legibility and natural-language-ness. It might just look well to keep that intact from /isLessSpecificThan/ to /isInRangeOf/.
>>>>>
>>>>> if (L.isInRangeOf(Level.DEBUG, Level.TRACE) --< oops does it work if the one is higher than the other, or the other way around?. I think the code should swap depending on condition, but I haven't looked at the code yet.
>>>>> ) {
>>>>> doSomethingElseEntirely();
>>>>> }
>>>>>
>>>>> ;-).
>>>>>
>>>>> Regards.
>>>>>
>>>>>
>>>>>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>>>>>
>>>>>> Hi All,
>>>>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>>>>>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>>>>>> Level)
>>>>>> This seems like right place which since we already have:
>>>>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>>>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>>>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the patch
>>>>>> (with tests).
>>>>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>>>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>>>>> OK, not OK?
>>>>>> Gary
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> 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
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: The Range of Levels
Posted by Ralph Goers <ra...@dslextreme.com>.
I had the same reaction when I first started looking at levels. In log4j1 it was worse since levels were ints, the value was always in your face. With enums it isn't quite as obvious. It is also why we renamed the level method that does the checking to something like "isLessSpecific" so the numeric value wouldn't show through.
As far as the numbers go, I had to just get over it. I suggest you do the same.
Sent from my iPad
> On Aug 28, 2015, at 5:07 AM, Xen <xe...@dds.nl> wrote:
>
> But that still doesn't make me understand because I don't know anything about those log4j 1 levels ;-).
>
> I was not criticising. I don't even know the numeric value of those levels at this point.
>
> It's just that, supposing FATAL has a low value, and TRACE has a high value (???)
>
> then how come I think of FATAL as high and TRACE as low? Or is it the other way around?.
>
> :P.
>
> Regards..
>
>
>> On 08/27/2015 06:07 PM, Remko Popma wrote:
>> Bart, the log4j2 int levels are based on the log4j 1 levels (multiplied by 100 to allow custom levels in between).
>> So this is historical, rather than anything else.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>>> On 2015/08/27, at 23:36, Xen <xe...@dds.nl> wrote:
>>>
>>> By the way,
>>>
>>> I know that regularly and naturally when you write your own debugging verbosity code you always use levels of 0 = no logging (or most important), 1 = a little more verbose, and so on. So 0 might amount to FATAL and 3 might amount to INFO. But I get the distinct impression from dealing with and perhaps using also log4j that it is the other way around.
>>>
>>> I get the impression, I don't know what from, that TRACE is actually "lowest" and FATAL is actually "highest". In the code, "isMoreSpecificThat" obviously deviates from and obviates the need to talk in high and low, since DEBUG is obviously more specific (if you think about it even two seconds) than INFO.
>>>
>>> Rather, I still have this impression that TRACE is "low" probably also because in the docs (pdf manual) they are located as such in the tables; it starts with TRACE and ends with FATAl (from left to right or top to bottom).
>>>
>>> Was this an intended consequence?. It seems also right to call FATAL "higher". A threshold also seems to indicate a "level that needs to be surpassed". Such that INFO is naturally "below" FATAL because FATAL goes "above" the threshold dictated for INFO. This is why it seems so natural for me to think this way. I also have never dealt with the numeric values directly.
>>>
>>> Was this intended?.
>>>
>>> Regards, Bart.
>>>
>>>
>>>
>>>
>>>
>>>> On Thu, 27 Aug 2015, Xen wrote:
>>>>
>>>> Seems pretty obvious to me, if you want my opinion.
>>>>
>>>> I'm not in love with the name, but I don't know what else.
>>>>
>>>> fallsWithin(level, level)
>>>>
>>>> maybe just
>>>>
>>>> isInRangeOf although very verbose, the other two methods are equally verbose. I think it would match. Personally I would choose either isInRangeOf or (perhaps ugly) fallsWithin.
>>>>
>>>> Cause if you're using verbs for method names you do so for legibility and natural-language-ness. It might just look well to keep that intact from /isLessSpecificThan/ to /isInRangeOf/.
>>>>
>>>> if (L.isInRangeOf(Level.DEBUG, Level.TRACE) --< oops does it work if the one is higher than the other, or the other way around?. I think the code should swap depending on condition, but I haven't looked at the code yet.
>>>> ) {
>>>> doSomethingElseEntirely();
>>>> }
>>>>
>>>> ;-).
>>>>
>>>> Regards.
>>>>
>>>>
>>>>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>>>>
>>>>> Hi All,
>>>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>>>>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>>>>> Level)
>>>>> This seems like right place which since we already have:
>>>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the patch
>>>>> (with tests).
>>>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>>>> OK, not OK?
>>>>> Gary
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> 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
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: The Range of Levels
Posted by Xen <xe...@dds.nl>.
But that still doesn't make me understand because I don't know anything
about those log4j 1 levels ;-).
I was not criticising. I don't even know the numeric value of those
levels at this point.
It's just that, supposing FATAL has a low value, and TRACE has a high
value (???)
then how come I think of FATAL as high and TRACE as low? Or is it the
other way around?.
:P.
Regards..
On 08/27/2015 06:07 PM, Remko Popma wrote:
> Bart, the log4j2 int levels are based on the log4j 1 levels (multiplied by 100 to allow custom levels in between).
> So this is historical, rather than anything else.
>
> Remko
>
> Sent from my iPhone
>
>> On 2015/08/27, at 23:36, Xen <xe...@dds.nl> wrote:
>>
>> By the way,
>>
>> I know that regularly and naturally when you write your own debugging verbosity code you always use levels of 0 = no logging (or most important), 1 = a little more verbose, and so on. So 0 might amount to FATAL and 3 might amount to INFO. But I get the distinct impression from dealing with and perhaps using also log4j that it is the other way around.
>>
>> I get the impression, I don't know what from, that TRACE is actually "lowest" and FATAL is actually "highest". In the code, "isMoreSpecificThat" obviously deviates from and obviates the need to talk in high and low, since DEBUG is obviously more specific (if you think about it even two seconds) than INFO.
>>
>> Rather, I still have this impression that TRACE is "low" probably also because in the docs (pdf manual) they are located as such in the tables; it starts with TRACE and ends with FATAl (from left to right or top to bottom).
>>
>> Was this an intended consequence?. It seems also right to call FATAL "higher". A threshold also seems to indicate a "level that needs to be surpassed". Such that INFO is naturally "below" FATAL because FATAL goes "above" the threshold dictated for INFO. This is why it seems so natural for me to think this way. I also have never dealt with the numeric values directly.
>>
>> Was this intended?.
>>
>> Regards, Bart.
>>
>>
>>
>>
>>
>>> On Thu, 27 Aug 2015, Xen wrote:
>>>
>>> Seems pretty obvious to me, if you want my opinion.
>>>
>>> I'm not in love with the name, but I don't know what else.
>>>
>>> fallsWithin(level, level)
>>>
>>> maybe just
>>>
>>> isInRangeOf although very verbose, the other two methods are equally verbose. I think it would match. Personally I would choose either isInRangeOf or (perhaps ugly) fallsWithin.
>>>
>>> Cause if you're using verbs for method names you do so for legibility and natural-language-ness. It might just look well to keep that intact from /isLessSpecificThan/ to /isInRangeOf/.
>>>
>>> if (L.isInRangeOf(Level.DEBUG, Level.TRACE) --< oops does it work if the one is higher than the other, or the other way around?. I think the code should swap depending on condition, but I haven't looked at the code yet.
>>> ) {
>>> doSomethingElseEntirely();
>>> }
>>>
>>> ;-).
>>>
>>> Regards.
>>>
>>>
>>>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>>>
>>>> Hi All,
>>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>>>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>>>> Level)
>>>> This seems like right place which since we already have:
>>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the patch
>>>> (with tests).
>>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>>> OK, not OK?
>>>> Gary
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> 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
>> ---------------------------------------------------------------------
>> 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: The Range of Levels
Posted by Remko Popma <re...@gmail.com>.
Bart, the log4j2 int levels are based on the log4j 1 levels (multiplied by 100 to allow custom levels in between).
So this is historical, rather than anything else.
Remko
Sent from my iPhone
> On 2015/08/27, at 23:36, Xen <xe...@dds.nl> wrote:
>
> By the way,
>
> I know that regularly and naturally when you write your own debugging verbosity code you always use levels of 0 = no logging (or most important), 1 = a little more verbose, and so on. So 0 might amount to FATAL and 3 might amount to INFO. But I get the distinct impression from dealing with and perhaps using also log4j that it is the other way around.
>
> I get the impression, I don't know what from, that TRACE is actually "lowest" and FATAL is actually "highest". In the code, "isMoreSpecificThat" obviously deviates from and obviates the need to talk in high and low, since DEBUG is obviously more specific (if you think about it even two seconds) than INFO.
>
> Rather, I still have this impression that TRACE is "low" probably also because in the docs (pdf manual) they are located as such in the tables; it starts with TRACE and ends with FATAl (from left to right or top to bottom).
>
> Was this an intended consequence?. It seems also right to call FATAL "higher". A threshold also seems to indicate a "level that needs to be surpassed". Such that INFO is naturally "below" FATAL because FATAL goes "above" the threshold dictated for INFO. This is why it seems so natural for me to think this way. I also have never dealt with the numeric values directly.
>
> Was this intended?.
>
> Regards, Bart.
>
>
>
>
>
>> On Thu, 27 Aug 2015, Xen wrote:
>>
>> Seems pretty obvious to me, if you want my opinion.
>>
>> I'm not in love with the name, but I don't know what else.
>>
>> fallsWithin(level, level)
>>
>> maybe just
>>
>> isInRangeOf although very verbose, the other two methods are equally verbose. I think it would match. Personally I would choose either isInRangeOf or (perhaps ugly) fallsWithin.
>>
>> Cause if you're using verbs for method names you do so for legibility and natural-language-ness. It might just look well to keep that intact from /isLessSpecificThan/ to /isInRangeOf/.
>>
>> if (L.isInRangeOf(Level.DEBUG, Level.TRACE) --< oops does it work if the one is higher than the other, or the other way around?. I think the code should swap depending on condition, but I haven't looked at the code yet.
>> ) {
>> doSomethingElseEntirely();
>> }
>>
>> ;-).
>>
>> Regards.
>>
>>
>>> On Wed, 26 Aug 2015, Gary Gregory wrote:
>>>
>>> Hi All,
>>> To make it easier to implement a LevelRangeFilter (patch with test here:
>>> https://issues.apache.org/jira/browse/LOG4J2-1106) I'd like to add a new
>>> method to the public API: org.apache.logging.log4j.Level.isInRange(Level,
>>> Level)
>>> This seems like right place which since we already have:
>>> - org.apache.logging.log4j.Level.isLessSpecificThan(Level)
>>> - org.apache.logging.log4j.Level.isMoreSpecificThan(Level)
>>> Please see https://issues.apache.org/jira/browse/LOG4J2-1105 for the patch
>>> (with tests).
>>> New API: https://issues.apache.org/jira/browse/LOG4J2-1105
>>> New Filter: https://issues.apache.org/jira/browse/LOG4J2-1106
>>> OK, not OK?
>>> Gary
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> 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
>
> ---------------------------------------------------------------------
> 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