logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: The Range of Levels
Date Fri, 28 Aug 2015 12:51:53 GMT
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 <xen@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 <xen@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


Mime
View raw message