logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xen <...@dds.nl>
Subject Re: The Range of Levels
Date Fri, 28 Aug 2015 12:07:43 GMT
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


Mime
View raw message