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

Ceki Gulcu listid at qos.ch
Fri Oct 3 10:25:27 CEST 2008


Ralph Goers wrote:
> 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. 
> 
> 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. 

Characterizing such overhead as "extremely small" does not sound right, 
"acceptable" is probably a better description.

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

I agree. Logging can cause "eye bleed" as anyone who has looked at log files for 
over 15 minutes can attest. Massive tracing output would just yield diminishing 
results. As you describe, you would have tracing disabled by default, and enable 
tracing only for specific classes.

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

Stopping and then restarting the application without the agent does exactly 
that, no? Do you mean hot injection/removal? That would be pretty hard to do.

> Ralph

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch



More information about the slf4j-dev mailing list