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]
