I wonder why we picked 100 instead of 1000 ;-) "No one will need more than 640k of memory"
http://www.computerworld.com/article/2534312/operating-systems/the--640k--quote-won-t-go-away----but-did-gates-really-say-it-.html G On Thu, Aug 27, 2015 at 9:07 AM, Remko Popma <remko.po...@gmail.com> 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 > > -- 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
