Hi Im new to Kotlin Logging and need some help 😄

Hi. I’m using KotlinLogging over log4j2 with extensive use of MDC and I wonder if there’s any solution or best practice to verify log calls in unit tests? Like, adding my own Appender or something?

Hi! Regarding MDC (with use of

withLoggingContext

). Is there considered any best practices for MDC and exceptions? The current implementation of withLoggingContext clears all MDC fields if an exception inside the flow occurs. I would very much like the exception to contain the MDC-information. One solution could be that

withLoggingContext

provides an option to provided an exception handler. (I think it is important not to couple the exception handling to close to the framework). Do you have any thoughts about this/what do you think? Or any suggestion on how the mdc is kept for exceptions? For my case I think the best use of an exception handler would be to add an “meta”-exception to the original exception (

addSuppressed

method ) (which is what I have done in my code, by creating a wrapper method around

withLoggingContext

)

The following test passes with version `2.1.23`and fails with version `3.0.4`:

import kotlinx.coroutines.runBlocking
import mu.KotlinLogging
import org.junit.jupiter.api.Test

internal class MdcTest {
    @Test
    fun testMdcContextBehavior() = runBlocking {
        withContext(MDCContext(mapOf("foo" to "bar"))) {
            logger.warn { "context should have bar" }
            assertEquals(MDC.get("foo"}), "bar")

            awaitAll(
                async { assertMdcContext("bar1") },
                async { assertMdcContext("bar2") }
            )

            logger.warn { "context should have bar " }
            assertEquals(MDC.get("foo"), "bar")
        }
    }

    private suspend fun assertMdcContext(id: String) {
        withContext(MDCContext(mapOf("foo" to id))) {
            logger.warn { "message with $id" }
            assertEquals(MDC.get("foo"), id)
        }
    }
}

Request for suggestions for version 4 https://github.com/MicroUtils/kotlin-logging/issues/264

hey, will kotlin-loggin support multiplatform mubile anytime soon?

There is android support and other platforms. What is missing exactly?

Hi, kotlin-logging 4.0 is soon to be GA. Will be happy it you try the beta to gather some final feedback:

io.github.oshai:kotlin-logging-jvm:4.0.0-beta-29

Is it possible to use

com.github.tony19:logback-android

with version 4?

I created an updated changelog for v.5: https://github.com/oshai/kotlin-logging/blob/master/ChangeLog.md

@oshai Hello oshai! i have a question about how to declare kotlin Logger! i have two cases using kotlin logger. They are under the below. 1. Declare K Logger as a member property of Spring Bean class 2. Declare top-level property of the file and sharing it on the same file. I read the recommended way that is no 2. But K Logger with Spring Bean, the logger’s life cycle is same with the spring bean, so there are no bad thing as a member property i think. What is your opinion and what is the recommended way?

I’m trying to upgrade a JVM based project from v3.x to v5.x. We have some places where we pass in a

KLogger

into some methods requiring a SLF4J

Logger

. In 5.x,

Klogger

no longer extends

org.slf4j.Logger

And so we can’t directly pass it in. In this comment for Issue 264, it was said:

The idea is that slf4j will still be supported, but instead of inheritance it will be via wrapping it.

I’m not seeing how to wrap a

KLogger

in order to make it useable as a SLF4J

Logger

. Any guidance?

Hi, anyone can give example how to add or configure sl4j, log4j, logback with current version 5.01. using org.slf4jslf4j simple2.0.3 does not meet my needs

Hi there, is there a way to use

internal

to allow visibility from other source modules in the same gradle project? E.g. I want to use some

internal

method defined in the main module from within the test module.

Quick question. I am migrating to 5.0 and I want to make sure I am not missing something. In previous versions, one could create a logger with

companion object : KLogging()

It appears that with 5.0, one has to explicitly create a logger value with

val logger = KotlinLogging.logger {}

. Is that correct?

yes, KLogging was deprecated in favour of one standard way to create a logger.

Figure maybe this is a better place to ask this question... https://kotlinlang.slack.com/archives/C7A1U5PTM/p1696295177886519

rg.gradle.api.tasks.TaskExecutionException: Execution failed for task 'appprocessDebugManifest'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:188) at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:186) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:174) at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109) at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195) at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75) at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62) at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79) at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54) at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52) at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:402) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:389) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:382) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:368) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61) Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.lang.String java.io.File.path accessib

anyone have idea about this issue?

Does anybody have a full stack trace from issue 188? The trace attached feels incomplete

How does

LocationAwareKLogger

actually grab the class name from which the log call is made? I can’t seem to find the relevant code. For context of why I’m asking: https://kotlinlang.slack.com/archives/CTJB58X7X/p1703144409394349

Hello, I see that in the new version 6, the changelog says "support Kotlin >= 1.9". Does this mean that if I upgrade my project to compile with Kotlin 1.9.*, I also need to upgrade to Kotlin-logging v6? Or does it mean the reverse, i.e. that in order to upgrade to use Kotlin-logging v6, I have to upgrade my Kotlin compiler to 1.9?

Hello! Does kotlin-logging support saving logs into file? 🤔 I am seeking something simillar to logback for android (https://github.com/tony19/logback-android)

Is there a post or any article which shows the difference between

kotlin-logger

vs Napier?

Hi, when doing logger.info { expr } - Can I avoid logging

null

? I do not want to do

expr?.<http://logger.info|logger.info> { it }

to avoid calculating the expr whatever the logging level.

How can I set the logging level for Android and iOS? By default, it is set to ‘info’, but I want to change it to ‘debug’. I can’t find any configuration for it

aside from kotlin-logging, what other Kotlin logging libraries are folks using (JVM only for me)? Looking for something that doesn’t bring along legacy baggage - kotlin-logging has a bunch of legacy API cruft, and most critically relies on MDC hacks that require

launch(MDCcontext())

all over the place or things break.

this exists.. have been using this on and off in some projects https://klogging.io/

Has anyone successfully solved structured logging in Ktor that allows modifying MDC outside of CallLogging plugin?

This message was deleted.