[logback-dev] Least-effort logging with bytecode modification

[Thorbjørn Ravn Andersen]

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.

> 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!"