On Wed, Nov 19, 2008 at 10:05 AM, Maarten Bosteels <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 18, 2008 at 7:30 PM, Thorbjørn Ravn Andersen <[EMAIL > PROTECTED]>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 >> > >
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
