The warn, error and fatal levels are hard coded to true as log4j does not even expose a isXXXEnabled for these levels. The internal implementation of the trace, debug, and info methods do an explicit level check before delegating the the log4j logger. For example:
public void info(Object message) {
if (infoEnabled) {
logger.log(FQCN, Priority.INFO, message, null);
}
}
-dain
On Thursday, August 14, 2003, at 03:14 AM, Alex Blewitt wrote:
On Thursday, Aug 14, 2003, at 06:31 Europe/London, Pasi Salminen wrote:
Putting my administrator hat on, I must say that I don't like application servers
which do not enable change of logging level at runtime.
Though personally I've not come across this before, I can see that it would be a desirable thing to have.
Berin Loritsch wrote:
For example:
if ( m_logger.isDebugEnabled() ) { m_logger.debug( "test message" ); }
is both slower and more cumbersome than this:
m_logger.debug( "test message" );
I will agree that there is more code. But bear in mind that w/o the debugging guard, the m_logger.debug("message") will almost certainly call m_logger.isDebugEnabled() (or access the boolean to do the test) anyway, so in the (common) case when debugging isn't enabled then IMHO it will make very little difference; possibly even run /faster/ with the guard.
Bear in mind that 'is slower' and 'is faster' are only likely to be based on what we humans think; until you've actually got code that is running, and it is demonstrable that this is where the bottleneck is, then pre-optimisation isn't worthwhile.
Alex.
/************************* * Dain Sundstrom * Partner * Core Developers Network *************************/
