On Wed, Nov 19, 2008 at 10:05 AM, Maarten Bosteels <mbosteels.dns@gmail.com>wrote:
On Tue, Nov 18, 2008 at 7:30 PM, Thorbjørn Ravn Andersen <ravn@runjva.com>wrote:
Robert Elliot skrev:
Thanks - I checked the slf4j-ext project when I started, but not the Subversion repository. I presume this is a post-compile step rather than runtime byte code alteration?
(I got the strange feeling of already having answered this, but I'm not sure, so I'll just do it again :)
Nope. Runs at class load time (i.e. at runtime).
Please look into the XLogger for actually doing the logging, as it is intended to allow keeping the information instead of flattening it into a string (you might want to be able to process this with a tool).
1) something like a PatternLayout to allow the user to choose the format of the messages at runtime (I prefer single > to double >> for instance on method entry - petty, but I feel it should be up to the user! And it's nice to be able to truncate parameter or return values if they are going to be utterly huge)
Would be nice. Also if it respects a different rendering than just the normal toString() approach.
2) trace logging of field value changes so you get output like this: fieldName initialValue -> newValue
Nice :)
3) loggers named after the class and method / field name, so you can be more fine grained in what output you get
Actually this is something I've noticed that java.util.logging can do - determine the method name of the caller - without any help. Perhaps this should be the approach? Let the logger do it?
4) passing the stacktrace to the output (depending on how you configure the pattern) so that if you are interested in what it was that changed the field or called the method you don't need trace logging on for the entire application
When you say stack trace, you talk about the call stack? I.e. asking the JVM for the stack and rendering it, instead of carrying an exception around? Just to get matters straight.
This is a really neat idea, which might also work well with the Eclipse Console plugin.
I cannot count the times I've pasted a stack trace in the Java Stack Trace pane on the Console to be able to navigate.
I am not sure we're talking about the same thing, but have you heard of JumpToCode ? It's a plugin for IntelliJ IDEA that listens for "jump to this code" commands from external programs. Creating a similar plugin for eclipse is on my TODO list.
The idea is that log-viewers such as Vigilog and Chainsaw show hyperlinks for every LocationInfo. When hyperlink is clicked a "jump to code" command is sent to your IDE, which will navigate to the corresponding code.
This is already implemented in Vigilog. I still have to ask the chainsaw maintainers to see if they are also interested.
forgot to add some URL's: http://code.google.com/p/firewood/wiki/JumpToCodePlugin http://plugins.intellij.net/plugin/?id=1894 http://vigilog.sourceforge.net/
Maarten
5) an @Secure annotation to allow the programmer to mark a parameter or return value as something that should not be accessible via trace logging - e.g. a password
Hmmmm.... I'm not sure of that. Lets see how it works out.
Out of curiousity (not criticising!) what was the reason for picking javassist rather than aspectj?
It worked :)
-- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev