logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bret Schuhmacher" <b...@ingrian.com>
Subject RE: isFatalEnabled()?
Date Fri, 15 Jun 2007 14:58:29 GMT
Thanks, Endre - that makes sense.  Yes, I was trying to test so I wouldn't have to do any String
concatenation and processing if the level was turned off.  Guess I was getting pretty anal
;-).  TRACE, DEBUG, and INFO ought to be enough.

Rgds,

Bret
--


> -----Original Message-----
> From: Endre StĂžlsvik [mailto:Endre@stolsvik.com]
> Sent: Friday, June 15, 2007 9:36 AM
> To: Log4J Users List
> Subject: Re: isFatalEnabled()?
> 
> Bret Schuhmacher wrote:
> > There are methods for isDebugEnabled and isInfoEnabled, but how do
> you
> > check for isFatalEnabled or any of the other levels? I've used
> > isEnabledFor(Priority.<level>), but Priority.FATAL and the rest are
> > deprecated, so what's the best way to test for the unrepresented
> > is<Level>Enabled levels?
> 
> There is isTraceEnbled too.
> 
> Just don't bother to test for them externally - they are always checked
> for inside log4j at any rate. It is assumed that there are rather few
> warnings, errors and fatals throughout an application, and that they
> mostly won't be turned off anyway, thus there isn't much need for the
> isEnabled methods. Those methods are only there to enable argument-
> construction bypass - that is, not having to actually make the log-
> message if logging for the particular level is turned off.
> 
> Endre.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org

Mime
View raw message