[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