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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
