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 _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
