logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James A. N. Stauffer" <stauffer.ja...@gmail.com>
Subject Re: conditional logging of exception
Date Fri, 21 Mar 2008 16:50:45 GMT
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,  <pico@mindspring.com> 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/%3cd54c36420710251039nae475e1p3e59fc7f00bd141f@mail.gmail.com%3e
>
>  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: log4j-user-unsubscribe@logging.apache.org
>  For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>



-- 
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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message