logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: The Range of Levels
Date Thu, 27 Aug 2015 16:39:36 GMT
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.popma@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 <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
>
>


-- 
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

Mime
View raw message