[logback-dev] Least-effort logging with bytecode modification
Thorbjørn Ravn Andersen
ravn at runjva.com
Tue Nov 18 19:30:02 CET 2008
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
> 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
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.
> Out of curiousity (not criticising!) what was the reason for picking javassist rather than aspectj?
It worked :)
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
More information about the logback-dev