At 10:49 AM 10/14/2006, you wrote:
>Hi All,
>I need to implements a user-level filter. I read in the archive some
>threads about that but I didn't found or i didn't understand the right way.
>I have a web application and I want to keep the log level to info or
>error and just set to debug for a single user.
>I know with MDC i'm able to track the username and i know there is a
>MDCFilter in order to filter the log that matches the filter.
>What I can do is to set to ALL the global level and then in the
>filter, to log only the record of the user/s I want.
>I think there is a big drawback in this approach. Basically my log
>calls are done checking first of all if the level is enable (code guard):
>
>if (log.isDebugEnable()) {
> log.debug(....);
>}
>
>in order to avoid the parameter evaluation if debug is disabled.
>Using MDCFilter all calls will be evaluated with a potentially big
>impact on the performance because the filters are evaluated when the
>log message is sent to the appenders.
>
Note that the guard is only there to protect against stuff like
concatenation...
log.debug("The variable value is " + value);
The above will have a performance impact. However, simply doing the
following without the guard is identical to using the guard. In
fact, inside each debug call, isDebugEnabled() is called before doing
anything else. So, actually, using the guard is very slightly more
expensive in the cases below...
log.debug(value);
OR
log.debug("This thing happened");
That said, getting back to your original point, yes; enabling the
debug level and using the filter to control appender output will have
a performance impact. I don't see any way around that other than
enhancing Log4j to augment the boolean guard methods. For instance,
it would be nice to be able to configure a guard handler for a
particular logger hierarchy that could perform extra evaluation
beyond whether the current Level is enabled. Come to think of it,
that would simply move the filter further up the chain from the
appender to the logger itself.
I haven't really thought about exactly how this might be done or how
practical it is, but it's something that could be considered for
Log4j-1.3 or maybe Log4j-2.0. Of course it is unlikely to happen
unless someone (hint hint) contributes the implementation.
comments anyone?
Jake
>Any help will is appreciated.
>Thanks in advance.
>
>Ste
>
>
>
>---------------------------------------------------------------------
>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]
