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" <[EMAIL PROTECTED]>
To: "logback developers list" <logback-dev@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@qos.ch
http://qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://qos.ch/mailman/listinfo/logback-dev

Reply via email to