Re: Suppressing stacktrace output
see
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Layout.html#ignoresThrowable()
If the layout handles the throwable object contained within LoggingEvent,
then the layout should return false. Otherwise, if the layout ignores
throwable object, then the layout should return true. The SimpleLayout,
TTCCLayout, PatternLayout all return true. The XMLLayout returns false.
For appenders that extend WriterAppender, the stacktrace will be appended by
the WriterAppender
when the layout ignores the throwable.
see
http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/WriterAppender.html#300
So I guess you could extend ConsoleAppender and override subAppend.
regards,
Maarten
On Thu, Mar 20, 2008 at 1:26 AM, jimski [EMAIL PROTECTED] wrote:
Hi James-
I think the layout determines if the stack trace is logged. How are
you configuring the console appender?
I thought so too. But it doesn't seem that's the case. I'm using the
following pattern:
[%d{-MM-dd HH:mm:ss}] %-5p %m %n
so I expect only a date, the level, the message and a newline character.
--
View this message in context:
http://www.nabble.com/Suppressing-stacktrace-output-tp16145551p16168549.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suppressing stacktrace output
OR subclass PatternLayout and add a setIgnoresThrowable(). Then use this
subclass in your console appender definition and add a property to disable:
...
log4j.appender.console.layout=com.mydomain.MyPatternLayout
log4j.appender.console.layout.IgnoresThrowable=false
...
(or whatever the XML equivalent is)
This approach would allow you to apply this behaviour to other appenders if
you wanted to later.
On Thursday 20 March 2008 5:15 am, Maarten Bosteels wrote:
see
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Layout.html#ig
noresThrowable()
If the layout handles the throwable object contained within LoggingEvent,
then the layout should return false. Otherwise, if the layout ignores
throwable object, then the layout should return true. The SimpleLayout,
TTCCLayout, PatternLayout all return true. The XMLLayout returns false.
For appenders that extend WriterAppender, the stacktrace will be appended
by the WriterAppender
when the layout ignores the throwable.
see
http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/WriterAppender.ht
ml#300
So I guess you could extend ConsoleAppender and override subAppend.
regards,
Maarten
On Thu, Mar 20, 2008 at 1:26 AM, jimski [EMAIL PROTECTED] wrote:
Hi James-
I think the layout determines if the stack trace is logged. How are
you configuring the console appender?
I thought so too. But it doesn't seem that's the case. I'm using the
following pattern:
[%d{-MM-dd HH:mm:ss}] %-5p %m %n
so I expect only a date, the level, the message and a newline character.
--
View this message in context:
http://www.nabble.com/Suppressing-stacktrace-output-tp16145551p16168549.h
tml Sent from the Log4j - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Absolute security comes with chains.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding a custom variable to Log4j logging calls
I suppose java.text.MessageFormat would do. For example:
log.debug(MessageFormat.format(Something happened; the context is [{1}],
myContextObj));
Although frankly, the simpler approach is something like this:
if (log.isDebugEnabled()) {
log.debug(Something happened; the context is [ +myContextObj +]);
}
The isDebugEnabled() call is an optimization technique. It allows the program
to skip the string construction if the log isn't going to write debug
messages anyway.
On Thursday 20 March 2008 9:07 am, dertown wrote:
that would work how would i format a message?
James A. N. Stauffer wrote:
Is there a reason why appending the strings doesn't work? I think you
can use format messages.
On Wed, Mar 19, 2008 at 9:57 AM, dertown [EMAIL PROTECTED]
wrote:
Hi Everyone
I am newbi with log4j , i was wondering if there is any example code
on how
to add a custom variable to a log4j logging call.
the default is log.log(DEBUG,log message);
I would like to add another custom variable here to allow for some
additional information.
so the new log call will be log.log(DEBUG,log message,more info);
Thanks
Derek
--
View this message in context:
http://www.nabble.com/Adding-a-custom-variable-to-Log4j-logging-calls-tp
16145549p16145549.html Sent from the Log4j - Users mailing list archive
at Nabble.com.
-
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]
--
Absolute security comes with chains.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Specifying TAG portion of syslog message in SyslogAppender
Question: How can users specify the tag portion of a syslog message using the SyslogAppender from log4j-1.2.15? According to section 4.1.3 of the BSD syslog protocol http://www.ietf.org/rfc/rfc3164.txt , it specifies that the message payload of a syslog message is composed of a 32 alphanumeric tag and the actual message. However, I see no way to currently do so short of configuring via an XML file that specifies a PatternLayout with a ConversionPattern hard coding the tag. My major grievance with this is because it requires the user to figure how to format log statements to work with syslog. If I had my say, there would be a simple tag property on the SyslogAppender along with its associated getter and setter methods. Whenever the user sets this via configuration, it would complain if the tag contains non-alphanumeric characters or exceeds the 32 character limit. Then whenever a message is logged, it would automatically prefix the message with the tag along with the necessary divider (left square bracket or colon). Thanks, Andrew R Feller, Analyst University Information Systems 200 Fred Frey Building Louisiana State University http://www.lsu.edu/ Baton Rouge, LA, 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax)
conditional logging of exception
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]
RE: conditional logging of exception
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]
Re: Adding a custom variable to Log4j logging calls
On Mar 20, 2008, at 9:59 AM, Tim Watts wrote:
I suppose java.text.MessageFormat would do. For example:
log.debug(MessageFormat.format(Something happened; the context is
[{1}],
myContextObj));
Although frankly, the simpler approach is something like this:
if (log.isDebugEnabled()) {
log.debug(Something happened; the context is [ +myContextObj
+]);
}
The isDebugEnabled() call is an optimization technique. It allows
the program
to skip the string construction if the log isn't going to write debug
messages anyway.
If you want to use MessageFormat, use LogMF in the extras companion (http://logging.apache.org/log4j/extras
), like:
LogMF.debug(log, Something happened: the context is [{0}] ,
myContextObj);
LogMF is highly optimized to minimize the overhead of using
MessageFormat, particularly for simple cases this.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I start Chainsaw without extra tabs
Thanks for the quick response. I have a few follow-up questions. I'm not sure how to prevent the zeroconf tab from being created (other than not having zeroconf dependencies in your Chainsaw classpath). We don't need zeroconf at all (we will always be accessing local log files). How do I go about removing these dependencies from the Chainsaw classpath? The Welcome tab visibility is a remembered preference in Chainsaw SVN trunk (not yet released version of Chainsaw). This has probably been answered elsewhere, but when is the next release scheduled that will include these changes. I would like to avoid running from a dev build if possible. You can prevent the chainsaw-log tab from being created by adding an 'org.apache.log4j' LOGGER entry to your Chainsaw log4j config file which sets the level to ERROR (or OFF). I had already tried this, or at least I thought I did, and it did not work. I still get the chainsaw tab and all log messages (all levels). Below is the content of my config file. Am I doing this wrong? ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; debug=true plugin name=Server Log class=org.apache.log4j.varia.LogFilePatternReceiver param name=fileURL value=file:///C /jboss/server/default/log/server.log/ param name=timestampFormat value=-MM-dd HH:mm:ss,SSS/ param name=logFormat value=TIMESTAMP LEVEL LOGGER MESSAGE/ param name=name value=Server Log/ param name=tailing value=true/ /plugin !-- Limit the org.apache category to ERROR -- category name=org.apache.log4j priority value=OFF/ /category root level value=debug/ /root /log4j:configuration Thanks again, Dave -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:05 PM To: log4j-user@logging.apache.org Subject: RE: How do I start Chainsaw without extra tabs I'm not sure how to prevent the zeroconf tab from being created (other than not having zeroconf dependencies in your Chainsaw classpath). The Welcome tab visibility is a remembered preference in Chainsaw SVN trunk (not yet released version of Chainsaw). You can prevent the chainsaw-log tab from being created by adding an 'org.apache.log4j' LOGGER entry to your Chainsaw log4j config file which sets the level to ERROR (or OFF). Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Dave Hensley [mailto:[EMAIL PROTECTED] Sent: Wed 3/19/2008 5:17 PM To: log4j-user@logging.apache.org Subject: How do I start Chainsaw without extra tabs Hi, I have created a startup config file that loads the receivers for my log files.this is working great. I would like to start Chainsaw without the application creating a chainsaw-log tab, Zeroconf tab, or the Welcome tab. I really don't need these tabs as we would like to use this to only view the log files from our app. We do not want, or need, to view any other log files. Can this be done? I know I can right-click and select Hide, but we would much rather start without the tab ever being created. Additionally, I am unable to even hide the Zeroconf or Welcome tabs as the Hide option is disabled on them. Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I start Chainsaw without extra tabs
If you're running Chainsaw from the Unix/DOS standalone download, you can remove jmdns.jar from the jars and run from the script...that'll prevent you from getting a zeroconf tab. If you run from the Web Start download, you probably can't avoid it. Also, you can press F1 to hide the welcome tab (you have to do that each time you launch Chainsaw). I can't say when the next version of Chainsaw will be released - it's dependent on some log4j extras that haven't yet been officially released. Once those dependencies have been released, a Chainsaw release should follow shortly after. It looks like you're doing the right thing to get org.apache.log4j entries to not be appended.. I used: logger name=org.apache.log4j level value=OFF/ /logger And I did still get some messages on an empty tab (-), but I didn't get a chainsaw-log tab. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Dave Hensley [mailto:[EMAIL PROTECTED] Sent: Thu 3/20/2008 6:04 PM To: 'Log4J Users List' Subject: RE: How do I start Chainsaw without extra tabs Thanks for the quick response. I have a few follow-up questions. I'm not sure how to prevent the zeroconf tab from being created (other than not having zeroconf dependencies in your Chainsaw classpath). We don't need zeroconf at all (we will always be accessing local log files). How do I go about removing these dependencies from the Chainsaw classpath? The Welcome tab visibility is a remembered preference in Chainsaw SVN trunk (not yet released version of Chainsaw). This has probably been answered elsewhere, but when is the next release scheduled that will include these changes. I would like to avoid running from a dev build if possible. You can prevent the chainsaw-log tab from being created by adding an 'org.apache.log4j' LOGGER entry to your Chainsaw log4j config file which sets the level to ERROR (or OFF). I had already tried this, or at least I thought I did, and it did not work. I still get the chainsaw tab and all log messages (all levels). Below is the content of my config file. Am I doing this wrong? ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; debug=true plugin name=Server Log class=org.apache.log4j.varia.LogFilePatternReceiver param name=fileURL value=file:///C /jboss/server/default/log/server.log/ param name=timestampFormat value=-MM-dd HH:mm:ss,SSS/ param name=logFormat value=TIMESTAMP LEVEL LOGGER MESSAGE/ param name=name value=Server Log/ param name=tailing value=true/ /plugin !-- Limit the org.apache category to ERROR -- category name=org.apache.log4j priority value=OFF/ /category root level value=debug/ /root /log4j:configuration Thanks again, Dave -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:05 PM To: log4j-user@logging.apache.org Subject: RE: How do I start Chainsaw without extra tabs I'm not sure how to prevent the zeroconf tab from being created (other than not having zeroconf dependencies in your Chainsaw classpath). The Welcome tab visibility is a remembered preference in Chainsaw SVN trunk (not yet released version of Chainsaw). You can prevent the chainsaw-log tab from being created by adding an 'org.apache.log4j' LOGGER entry to your Chainsaw log4j config file which sets the level to ERROR (or OFF). Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Dave Hensley [mailto:[EMAIL PROTECTED] Sent: Wed 3/19/2008 5:17 PM To: log4j-user@logging.apache.org Subject: How do I start Chainsaw without extra tabs Hi, I have created a startup config file that loads the receivers for my log files.this is working great. I would like to start Chainsaw without the application creating a chainsaw-log tab, Zeroconf tab, or the Welcome tab. I really don't need these tabs as we would like to use this to only view the log files from our app. We do not want, or need, to view any other log files. Can this be done? I know I can right-click and select Hide, but we would much rather start without the tab ever being created. Additionally, I am unable to even hide the Zeroconf or Welcome tabs as the Hide option is disabled on them. Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
