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 <[email protected]> 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: [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]
---------------------------------------------------------------------
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]
