How to make groovy @Log annotation not safeguard calls inside closures

Vote count:

0

I use the @Slf4j annotation to add a logging to my groovy classes.

I like it because of the AST transformation that wraps my log calls in inside an "enablement" check, documented here

What I've found though, is that the guard clause doesn't work if the log method is called from within a closure.

Running on Groovy 2.2.0, this code logs only one message, but prints "called" twice.

@Grapes([
  @Grab(group='org.slf4j', module='slf4j-api', version='1.7+'),
  @Grab(group='ch.qos.logback', module='logback-classic', version='1.+')])
import groovy.util.logging.Slf4j

new TestCode().doSomethingThatLogs()

@Slf4j
class TestCode {
  void doSomethingThatLogs(){
    log.info createLogString(1)
    log.trace createLogString(2)
    Closure c = { log.trace createLogString(3) }
    c()
  }

  String createLogString(int p){
    println "called with $p"
    return "blah: $p"
  }
}

I've tried adding "this" and "owner" specifiers to the log statement but same result.

The context I found this in was when I was trying to log some nodes using XmlUtil.serialize when while parsing XML with XmlSlurper.

I'm working around the problem by wrapping the NodeChild object in a lightweight object with a toString() method that calls the XmlUtil class. That'll work fine and the overhead of the extra wrapper classes is not worth worrying about. I'm more interested in finding a simple way around this problem so that I can go back to not having to think about the cost of construction of logging messages when they aren't being logged anyway.

The question I'm asking: is there any way to have the logging level guard clause work properly within closures, instead of having to add the "log.traceEnabled" calls myself?

asked 4 mins ago

Shorn

1,015