Source: http://markmail.org/message/wwuof7nquwqs46sg

On Mar 5, 2013 1:00:51 am Jochen Theodorou wrote:

> I don't know about Slf4j / logback, but such tools have the tendency
> to assume the stack frame before is what is to be used for such
> information. In Groovy as well as in many other languages than Java or
> if you do Reflection/Lambdas/invokedynamic this is not true anymore,
> resulting in wrong information

Indeed. Logback assumes that the stack trace element occurring just after logback's external boundary is that of the caller. Here is the relevant stack trace as seen by logback when invoked by groovy.

note: c.q.l.c stands for ch.qos.logback.classic

... [cut]
c.q.l.c.Logger.appendLoopOnAppenders(Logger.java:280) <- within logback
c.q.l.c.Logger.callAppenders(Logger.java:267) <- within logback
c.q.l.c.Logger.buildLoggingEventAndAppend(Logger.java:449) <- within logback
c.q.l.c.Logger.filterAndLog_0_Or3Plus(Logger.java:403) <- within logback
c.q.l.c.Logger.debug(Logger.java:510) <- within logback (external boundary)
org.slf4j.Logger$debug.call(Unknown Source) <- caller according to logback
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)

org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
com.foo.LineNumTest.foo(LineNumTest.groovy:13) <- actual caller
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method),
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
... [cut]

Logback needs to adjust it's algorithm so that the caller is assumed to be following "org.codehaus.groovy.runtime.callsite". Presumably, the fully defined class name of the caller depends on the version of grovvy, i.e it may not always be "org.codehaus.groovy.runtime.callsite". To accommodate that
possibility, logback can check for the more generic "org.codehaus.groovy".