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 <x...@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 <x...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
