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. 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 > [email protected] > http://qos.ch/mailman/listinfo/logback-dev >
_______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
