Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-811

Caller data is not correctly computed when run under groovy

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.9
    • Fix Version/s: 1.0.10
    • Component/s: None
    • Labels:
      None
    • Environment:

      Groovy 2.0.x

      Description

      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".

        Attachments

          Activity

            People

            • Assignee:
              ceki Ceki Gülcü
              Reporter:
              ceki Ceki Gülcü
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: