I dont really understand your thoughts why an error should not be logged along
with stack trace, since it is an exceptional situation which should not occur
often. Errors in logs are never "noise ratio".
But your problem with classname, linenummer etc. can be solved if you use the
overloaded log method which takes as first parameter the FQCN. FQCN is then the
one of the calling class.
Your static method:
public static void logVerboseOnLevel( Object instance, Logger logger, Level
thresholdLevel, Exception e, Level logAtLevel)
{
if (logger.isEnabledFor(thresholdLevel))
{
logger.log( instance.getClass.getName(), logAtLevel, e, e);
} else {
logger.log( instance.getClass.getName(), logAtLevel, e);
}
}
and called like:
Logger logger = Logger.getLogger(getClass);
Wrapper.logVerboseOnLevel( this, logger, Level.DEBUG, new
Exception(), Level.ERROR);
>>>>>> NOT TESTED, just hacked in by mind.
Heri
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2008 8:07 PM
> To: log4j-user@logging.apache.org
> Subject: [SPAM (Bayesain Analysis)] - conditional logging of
> exception -
> Bayesian Filter detected spam
>
>
> 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/20
0710.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]
