[infinispan-dev] trace vs log.isTraceEnabled

[Sanne Grinovero]

On 7 December 2011 12:20, Bela Ban <bban at 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.