[logback-dev] Least-effort logging with bytecode modification
listid at qos.ch
Tue Nov 18 18:54:40 CET 2008
Robert Elliot wrote:
> 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.
Bytecode engineering may indeed by easier to "deploy" assuming that
you have some control over the JVM. As you point out, that
assumption may not always be correct.
> 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
I encourage you to look into the work done by Thorbjørn. I think
he would welcome your mindful input.
Logback: The reliable, generic, fast and flexible logging framework for Java.
More information about the logback-dev