Actually we're not talking about log4j category loggers... we're
talking about slf4j loggers. I point that out only because I'm using
logback, not log4j. Nevertheless, I think I've found a good enough
solution for the time being... adding an appender filter. The primary
offender in the DEBUG level is the message that logs what class
transformation has been performed. It always begins with the string
"Finished class transformation:". Therefore I've added a filter that
will deny all messages that begin with that string. Here is my
logback appender configuration, though I'm pretty sure log4j supports
basically the same thing...
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<filter class="ch.qos.logback.core.filter.EvaluatorFilter">
<evaluator name="REMOVE_TAPESTRY">
<expression>message.startsWith("Finished class
transformation:")</expression>
</evaluator>
<OnMismatch>NEUTRAL</OnMismatch>
<OnMatch>DENY</OnMatch>
</filter>
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>%d{HH:mm:ss.SSS} %-5level %logger{36} - %msg%n</Pattern>
</layout>
</appender>
This works for DEBUG since that single log message was causing me the
most grief. However, in TRACE it would likely be many more. Perhaps
a specific string can be prepended to T5 framework log messages, so
that they can be filtered out in the logger configuration? Is that
already possible by some global configuration, or should I add an issue?
-will
On Jan 4, 2008, at 11:19 AM, Fernando Padilla wrote:
I'm sorry, but no. They do not come from different loggers. What are
you talking about?
We are talking about log4j category loggers. And tapestry is using
the
classname of the page, and we're using the classname of the page
(which
is the standard), and hence we can't change the loglevel of what
tapestry outputs, without changing the log level of what our own code
outputs...
Have you seen this on your server?
Have you dealt with this yourself?
Hugo Palma wrote:
You can differentiate. They come from different loggers.
You can configure log4j(if that's what your using) to ignore(or
send to
another appender) DEBUG and TRACE messages from Tapestry.
Will Norris wrote:
My concern isn't ERROR and FATAL messages being lost in the noise...
that can easily be done with some logging configuration as you've
suggested. My concern is my own DEBUG and TRACE messages being lost
in the noise, since there is no way to differentiate my own messages
from those generated by Tapestry.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
