Two options that come to mind:
1. Use 2 appenders with only one logging the exception. Then when you
would normally change the level you would change the appender.
2. If it is code that you control you could log the exception at a
lower level (i.e. info) so you don't see them when the threshhold is
at error.
On Thu, Mar 20, 2008 at 1:06 PM, <[EMAIL PROTECTED]> wrote:
> Hello,
>
> For a webapp, it would be nice to be able to conditionally log stack trace
> along
> with exception.
>
> Scenario:
>
> (1) Production application ships with Level set to Level.ERROR.
> (2) An app admin notices some errors in the log [Logger.error(Object)].
> (3) A means is available [Logger.setLevel()] to dynamically set Level to
> Level.DEBUG
> for a particular class.
> (4) When the error occurs again, the stack trace is logged along with the
> error
> [Logger.error(Object, Throwable)].
>
> A solution would be to have a wrapper class with a static method like:
>
> public static void logVerboseOnLevel(Logger logger, Level thresholdLevel,
> Exception
> e, Level logAtLevel) {
> if (logger.isEnabledFor(thresholdLevel)) {
> logger.log(logAtLevel, e, e);
> } else {
> logger.log(logAtLevel, e);
> }
> }
>
> and called like:
>
> Logger logger = Logger.getLogger(getClass);
> Wrapper.logVerboseOnLevel(logger, Level.DEBUG, new Exception(), Level.ERROR);
>
> If logger level is ERROR, just the one liner is logged. If logger level is
> DEBUG,
> the stack trace is logged.
>
> The benefit is to minimize the amount of information in the log file, unless
> the
> cause of the exception is being sought. Since it is possible to set log
> level per
> class, the signal to noise ratio is much more conducive to finding the
> problem.
>
> In log4j.properties, the appender is defined like:
>
> log4j.appender.MY_APPENDER.layout.ConversionPattern=%d [%t] %-5p %c:%l
> %C:%-4L
> - %m%n
>
> The portion "%C:%-4L" means I want the class and line number where the
> problem occurred. This conflicts with the wrapper, as its class and line
> number
> are the ones used to invoke log4j. Also, it would be nice to only use the
> wrapper
> class in specialized situations. So any solution would need to handle both
> the
> straightforward Logger use case, as well as the wrapper.
>
> There is an old post on this forum describing a similar problem, but I
> couldn't
> really figure out how to utilize the responses.
>
>
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/200710.mbox/[EMAIL
> PROTECTED]
>
> Originally I had the chunk of code above copied in each specialized place
> where
> I needed it, then I refactored the copies into a utility class, and ran into
> the
> logging output issue.
>
> Any suggestions for a solution to this usage case?
>
> Thanks...
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
James A. N. Stauffer http://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
