Wrong class name printed when using LoggingEventBuilder with payload

oshai / kotlin-logging

Lightweight Multiplatform logging framework for Kotlin. A convenient and performant logging facade.

Other

2.51k stars 110 forks source link

Wrong class name printed when using LoggingEventBuilder with payload #416

Closed MzrW closed 1 month ago

MzrW commented 1 month ago

The wrong class name is printed when using the LoggingEventBuilder with a payload.

The following example demonstrates the issue:

package my.pkg

import io.github.oshai.kotlinlogging.KotlinLogging

private val logger = KotlinLogging.logger {  }

fun main() {
    logger.atInfo {
        message = "hi"
        payload = mapOf("k" to "v")
    }

    logger.atInfo {
        message = "hi"
    }
}

Which will print:

Apr. 06, 2024 4:49:02 AM io.github.oshai.kotlinlogging.slf4j.internal.LocationAwareKLogger logWithPayload
INFORMATION: k=v hi
Apr. 06, 2024 4:49:02 AM my.pkg.MyClassKt main
INFORMATION: hi

The first log statement will be logged with io.github.oshai.kotlinlogging.slf4j.internal.LocationAwareKLogger as a classname. Which is wrong. It supposed to be my.pkg.MyClassKt.

In the second log statement however it seems to work fine.

Check out the example to reproduce the issue: example.zip

github-actions[bot] commented 1 month ago

Thank you for reporting an issue. See the wiki for documentation and slack for questions.

MzrW commented 1 month ago

The difference seems to be inside LocationAwareKLogger.

Log statements without payload are logged using: org.slf4j.spi.LocationAwareLogger.log(org.slf4j.Marker marker, String fqcn, int level, String message, Object[] argArray, Throwable t)

Log statements with payload are logged using: org.slf4j.spi.LoggingEventBuilder.log(String message). LocationAwareKLoggger.logWithPayload seems to correctly set the callerBoundary.

The first thing org.slf4j.spi.DefaultLoggingEventBuilder.log(String message) does is to override the callerBoundary with its own classname.

Therefore I think the bug is inside slf4j not in kotlin-logging.

Maybe leave the issue open until the bug is resolved there ...