It's best to check for "isDebugEnabled", etc., externally if performance
is a consideration, since an external test avoids the time-consuming
concatenating and formatting strings if it won't be used. If you use
the test inside log4j, you will pay the penalty for these operations,
even if they are not going to be logged. This ability is a key feature
of log4j and all other good logging systems. --Wayne
Endre Stølsvik wrote:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
