Thorbjørn Ravn Andersen wrote: > >> 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? > > Why? Logback already gives automatically gives you access to the class and method name. > >> 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. > > >> 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. > One of my development teams have actually implemented this with some of the AOP stuff then have done. I'll be looking at that soon for addition to SLF4J.
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
