logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: stacktrace information logger patch...
Date Wed, 29 Dec 2004 13:01:37 GMT

Hi Kevin,

My comments below are entirely based  on the use case where you have a
log statement indicating some method,  say X, was called. However, you
do not know  how, why or who called X. That  is where your %stacktrace
word comes into play.

Your  current contribution  is a  good step  forward but  not entirely
sufficient to  address the above use  case. If you use  the long form,
since all  logging output will  contain a stacktrace, your  log output
will be long and verbose making it hard to  decipher. If you use
the short  form, the log  output will be  easier to read. However, a single
line of stack trace may not  be enough to clearly understand the chain
of events  resulting in the invocation  of X. You need  more slack with
more lines of stack.

So, instead of full/short, make the argument to %stacktrace an integer
specifying the  lines of stack to  print. With no  arguments, the full
stack trace should be printed.

The  second more  elaborate enhancement  comes in  the form  of filter
chains. Define a filter chain  which returns a positive value only for
logs containing the output from X.  When you pass that filter chain to
%stacktrace. it should  be able to output a stack  trace *only* for X,
ignoring the other logging events.  This will result in a much cleaner
log output allowing you to quickly focus on the actual problem.

Here is a configuration file to make my clarify the point.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration>

<configuration xmlns='http://logging.apache.org/'>

   <!-- In case log4j does not alreasy know about the stackTrace conversion 
word,
        we can also teach it on the fly -->
   <conversionRule conversionWord="stackTrace"
                   converterClass="org.apache.log4j.pattern.StacktraceInformationPatternConverter"/>

   <!- The XYHunting filter chain will return DENY, except for output 
generated by
       X in which case it will return ACCEPT. -->
   <filterChain name="BUG_HUNTER">

     <filter class="org.apache.log4j.varia.StringMatchFilter">
       <param name="StringToMatch" value="Something output by X" />
       <param name="AcceptOnMatch" value="true" />
     </filter>

     <filter class="org.apache.log4j.varia.DenyAllFilter"/>

   </filterChain>

   <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%d{HH:mm:ss,SSS} %-5p [%t] %c 
- %m%n%stackTrace{BUG_HUNTER}"/>
     </layout>
   </appender>

   <root>
     <level value ="debug"/>
     <appender-ref ref="CONSOLE" />
   </root>
</configuration>


If you were also hunting for Y, then you could easily change the
filter chain. For example,

   <!- The XYHunting filter chain will return DENY, except for output 
generated by
       X or Y in which case it will return ACCEPT. -->
   <filterChain name="BUG_HUNTER">

     <filter class="org.apache.log4j.varia.StringMatchFilter">
       <param name="StringToMatch" value="Something output by X" />
       <param name="AcceptOnMatch" value="true" />
     </filter>

     <filter class="org.apache.log4j.varia.StringMatchFilter">
       <param name="StringToMatch" value="Something output by Y" />
       <param name="AcceptOnMatch" value="true"/>
     </filter>

     <filter class="org.apache.log4j.varia.DenyAllFilter"/>

   </filterChain>

The above is just to give you an idea. Log4j has more powerful filters.

If    you    agree    with     the    above,    you    could    enhace
StacktraceInformationPatternConverter  (SIPC)  by  calling the  filter
chain passed by reference  (the BUG_HUNTER string).  SIPC can retrieve
it from  the object store  in the LoggingRepository.  When  the filter
chains   returns  Filter.ACCEPT,  SIPC   should  output   stack  trace
information, if the filter chain returns another value, then it should
NOT ouput any  stack trace info, resulting in  the generation of stack
trace info but for the spots where its needed.

You would also need to define a joran action to build the filter chain
and add this filter chain to the Logger Repository. The call should be
akin to:

   repository.addObject("BUG_HUNTER", filterChain);


Here are some Joran tips:

- For the rationale behind Joran see http://www.qos.ch/logging/joran.pdf

- You can also find a whole bunch of actions under
   $LOG4J_HOME/src/java/org/apache/log4j/joran

- There is a short tutorial with several examples under
   $LOG4J_HOME/examples/src/joran

There is only  one missing architectural piece from  our end. Although
Logger,  Appender   and  Layout  objects  hold  a   reference  to  the
LoggerRepository where they are embedded, PatternConverters do not. If
you are interested, I can quickly fix this shortcoming.



At 03:39 AM 12/24/2004, Kevin A. Burton wrote:
>This is a quick implementation of a %stacktrace pattern converter to 
>create exceptions when a stack trace is logged.
>
>I added documentation in PatternLayout right below %throwable.
>
>It also supports the {short} operator for just the first line.
>
>Anyway... The best documentation is the source.
>
>Comments welcome!
>
>Kevin
>
>--

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



---------------------------------------------------------------------
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