[slf4j-dev] svn commit: r1155 - in slf4j/trunk/slf4j-ext/src/main/java/org/slf4j: agent instrumentation

[Thorbjørn Ravn Andersen]

Ralph Goers skrev:
> XLogger just provides some basic "extended" methods in a standardized 
> way. I would prefer that rather than use _log.debug you would use 
> XLogger.entry as it makes filtering them easier. 
>   
Let us come back to that later.

> In our code we manually add entry, exit, caught, etc. to everything 
> except simple getters and setters. The overhead of this when they are 
> not enabled is extremely small. But, as is noted in many AOP books, it 
> is somewhat distracting and is kind of a pain to have to do manually.  
> But the benefit is enormous. In development it is a great learning tool 
> and is helpful in debugging. In production we will sometimes turn it on 
> but only for a small set of classes as the volume of output is way too 
> large. Usually we will enable the other debug messages but leave flow 
> tracing disabled.
>   
Is there any particular reason you have not looked into using e.g. 
AspectJ yet. 

I agree on the pain on having to write all that framework code...  
Tedious but rewarding :)

What you are basically getting is what the debugger would give you, but 
time-independent, so you can look at stuff post-mortem.


> What would be better, if it is possible, is to inject the logging 
> dynamically when needed and completely remove it when not, eliminating 
> any performance overhead at all.
>   
It is possible :) 

If you build the 1.5.4-SNAPSHOT version of slf4j-ext and put 
javassist.jar next to it, you can insert 
"-javaagent:slf4j-ext-1.5.4-SNAPSHOT.jar" in your usual java invocation 
(from memory) and have a quick instrumentation of a smallish program.  
Note it is not production code :) 

/Thorbjørn