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

[Maarten Bosteels]

On Tue, Nov 18, 2008 at 7:30 PM, Thorbjørn Ravn Andersen <ravn at runjva.com>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
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://qos.ch/pipermail/logback-dev/attachments/20081119/6331be6b/attachment-0001.htm