At 08:25 AM 1/3/2005, Kevin A. Burton wrote:
Ceki G�lc� wrote:
The second more elaborate enhancement comes in the form of filter
chains. Define a filter chain which returns a positive value only for
logs containing the output from X. When you pass that filter chain to
%stacktrace. it should be able to output a stack trace *only* for X,
ignoring the other logging events. This will result in a much cleaner
log output allowing you to quickly focus on the actual problem.
Here is a configuration file to make my clarify the point.
Wow... that seems like a big CPU hit.
I'd expect the CPU hit to be minimal because the filter chain will
only be applied on enabled log statements. For the vast majority of
events the filter will not match. In the case of two unequal string,
string comparison returns very quickly. I'd go as far as speculating
that the CPU hit would be beyond the measurable.
I actually just thought it would be good to log an individual class. So
you just define your categoriy as org.peerfear.ClassToDebug and then use
that with your %stacktrace ... which would be a lot faster.
If you direct the logs of an individual class, then you will be
loosing the information provided by the larger context, i.e. the
information provided by the surrounding logs. If that context is not
important, then obviously your approach is much simpler.
Kevin
--
Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
