Re: [infinispan-dev] trace vs log.isTraceEnabled
On 7 December 2011 12:20, Bela Ban <bban(a)redhat.com> wrote:
[...]
Better, but this is awkward code IMO. You have to introduce additional
variables before tight loops, hmm...
I used to do (in JGroups):
public static final boolean trace=true;
and
#1 if(trace && log.isTraceEnabled()) {
#2 log.trace();
#3 }
If I wanted to create a version without tracing, I compiled JGroups with
trace=false. The compiler would then optimize lines 1-3 away.
Turns out this was awkward and I removed it in the next release, as I
couldn't change the logging at runtime (e.g. via probe.sh).
My current philosophy is that I do use the "if(log.isTraceEnabled()
log.trace()" pattern, but I use it wisely, and I try not to use this in
tight loops, or frequently traversed code paths.
yes in my longer email above I propose something along those lines: to
use trace for non-modifiable levels, and stick with debug if you think
runtime changes should be allowed.
Ideally we could use constants all the time and have a Java agent
redefine the class definition when needing to change the constant: an
expensive change but it would trigger only when someone actually
changes the logging level.