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: [email protected] | [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
