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

[Maarten Bosteels]

On Wed, Nov 19, 2008 at 10:05 AM, Maarten Bosteels
<mbosteels.dns at gmail.com>wrote:

> 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.
>

forgot to add some URL's:

http://code.google.com/p/firewood/wiki/JumpToCodePlugin
http://plugins.intellij.net/plugin/?id=1894
http://vigilog.sourceforge.net/


>
> 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/96fe9b73/attachment.htm