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

[Robert Elliot]

Sorry, I guess I was thinking that you could be modifying the byte code as a post compile step, if you see what I mean, but closer inspection of the discussion should have shown me you were talking about instrumentation at runtime.

I see the difference as one of problems for the end user.  Using instrumentation at runtime requires the end user to alter how they run their JVM - this is always going to add to the complications of getting it running, and may be an insurmountable problem in terms of ever doing it in a production environment, it's the sort of thing that is going to make admin people nervous!  I thought the general rule of thumb was that instrumentation is a development rather than a production tool, though perhaps that's a misconception.  I wanted something that would give me classes that could just be deployed into an existing production environment without needing to change any startup scripts - aspectj, by operating at compile time, does that.

The case for the instrumentation approach, I guess, is that it can be added after the fact without needing to recompile the entire codebase.  Also it doesn't require any alteration to your build and the logging isn't embedded in your class files, which may feel cleaner.

I very much wanted something like this on my last project to allow debugging of a very intermittent issue that only occured on production, where the programmer inserted log statements weren't helping me out and where even restarting the server, let alone deploying altered code, was going to be painful.  In that case the instrumentation method would have been more useful, so perhaps it's the best way.

I'm tempted to suggest that having both options would be nice, but on the other hand there's the issue of how they would interact - be a little irritating if you instrumented a class which already had aspect based trace logging.  I haven't looked at the slf4j-ext code hard enough to know how configurable it is in terms of which classes get instrumented, though I presume that wouldn't be too difficult to achieve.

Rob

----- Original Message -----
From: "Ceki Gulcu" <listid at qos.ch>
To: "logback developers list" <logback-dev at qos.ch>
Sent: Tuesday, 18 November, 2008 4:23:37 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [logback-dev] Least-effort logging with bytecode modification

Hello Robert,

Robert Elliot wrote:
 > 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?

No, the Agent extensions perform byte code engineering at
runtime. BTW, the subject of this thread is "Least-effort logging with
*bytecode* modification".

 > Out of curiousity (not criticising!) what was the reason for picking
 > javassist rather than aspectj?

I think the goal was to add logging at runtime. Can you do byte code
engineering with AspectJ? I'll let Thorbjørn give a more authoritative
answer.

It looks like you have already done some work using AspectJ-generateed
logging. How useful do you find the results, mildly useful, useful, or
very useful?

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
logback-dev mailing list
logback-dev at qos.ch
http://qos.ch/mailman/listinfo/logback-dev