Ceki G�lc� wrote:
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.
Well I agree.. I think I even noted this in the source if you read all the comments ;)
Here's what I said inline:
//NOTE: when option is an integer here we could just return this many
//lines. As an example you could have %stacktrace{5} and only return 5
//lines of the stack.
I didn't consider this to be a big feature for my development style so I didn't implement this right away.
Note that if you're correct here then this same thing applies to %throwable which doesn't implement this behavior.
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.
Yes...
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.
Wow... that seems like a big CPU hit.
I actually just thought it would be good to log an individual class. So you just define your categoriy as org.peerfear.ClassToDebug and then use that with your %stacktrace ... which would be a lot faster.
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.
If you want to attempt all this work then you should backport the same functionality for %throwable. IMO I just think we need this basic support ASAP and then if necessary we can add it in later.
Remember the current log4j doesn't have this feature at ALL .. so these can just be RFEs for later.
Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod!
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
