LogContextHolder
Holds and propagates the active LogContext for the current execution scope.
This object is implemented per-platform to use the most appropriate scoping mechanism (e.g. ThreadLocal on JVM/Android, a thread-local stack on Apple targets).
Contexts are scoped: the previous context is always restored after withContext completes, even if the block throws. Nested calls merge their contexts - inner values override outer values for the same key.
Example:
val requestContext = LogContext(mapOf("requestId" to "req-123"))
val result = LogContextHolder.withContext(requestContext) {
logger.info { "Handling request" }
processRequest() // return value is propagated
}Holds and propagates the active LogContext for the current execution scope.
This object is implemented per-platform to use the most appropriate scoping mechanism (e.g. ThreadLocal on JVM/Android, a thread-local stack on Apple targets).
Contexts are scoped: the previous context is always restored after withContext completes, even if the block throws. Nested calls merge their contexts - inner values override outer values for the same key.
Example:
val requestContext = LogContext(mapOf("requestId" to "req-123"))
val result = LogContextHolder.withContext(requestContext) {
logger.info { "Handling request" }
processRequest() // return value is propagated
}Holds and propagates the active LogContext for the current execution scope.
This object is implemented per-platform to use the most appropriate scoping mechanism (e.g. ThreadLocal on JVM/Android, a thread-local stack on Apple targets).
Contexts are scoped: the previous context is always restored after withContext completes, even if the block throws. Nested calls merge their contexts - inner values override outer values for the same key.
Example:
val requestContext = LogContext(mapOf("requestId" to "req-123"))
val result = LogContextHolder.withContext(requestContext) {
logger.info { "Handling request" }
processRequest() // return value is propagated
}Holds and propagates the active LogContext for the current execution scope.
This object is implemented per-platform to use the most appropriate scoping mechanism (e.g. ThreadLocal on JVM/Android, a thread-local stack on Apple targets).
Contexts are scoped: the previous context is always restored after withContext completes, even if the block throws. Nested calls merge their contexts - inner values override outer values for the same key.
Example:
val requestContext = LogContext(mapOf("requestId" to "req-123"))
val result = LogContextHolder.withContext(requestContext) {
logger.info { "Handling request" }
processRequest() // return value is propagated
}Holds and propagates the active LogContext for the current execution scope.
This object is implemented per-platform to use the most appropriate scoping mechanism (e.g. ThreadLocal on JVM/Android, a thread-local stack on Apple targets).
Contexts are scoped: the previous context is always restored after withContext completes, even if the block throws. Nested calls merge their contexts - inner values override outer values for the same key.
Example:
val requestContext = LogContext(mapOf("requestId" to "req-123"))
val result = LogContextHolder.withContext(requestContext) {
logger.info { "Handling request" }
processRequest() // return value is propagated
}Kotlin/Native coroutines are not single-threaded - Dispatchers.Default is a multi-threaded worker pool. Without ThreadLocal this object's state would be one process-wide slot, so concurrent coroutines on different threads would read each other's context - i.e. silently wrong context data.
ThreadLocal gives each thread its own slot, matching the ThreadLocal used on JVM/Android and NSThread.threadDictionary on Apple. A coroutine that resumes on a different thread therefore sees an empty context rather than another coroutine's: it fails closed. Reinstalling context across a thread hop needs a ThreadContextElement, which kotlinx.coroutines only ships on JVM.
Kotlin/Native coroutines are not single-threaded - Dispatchers.Default is a multi-threaded worker pool. Without ThreadLocal this object's state would be one process-wide slot, so concurrent coroutines on different threads would read each other's context - i.e. silently wrong context data.
ThreadLocal gives each thread its own slot, matching the ThreadLocal used on JVM/Android and NSThread.threadDictionary on Apple. A coroutine that resumes on a different thread therefore sees an empty context rather than another coroutine's: it fails closed. Reinstalling context across a thread hop needs a ThreadContextElement, which kotlinx.coroutines only ships on JVM.
Holds and propagates the active LogContext for the current execution scope.
This object is implemented per-platform to use the most appropriate scoping mechanism (e.g. ThreadLocal on JVM/Android, a thread-local stack on Apple targets).
Contexts are scoped: the previous context is always restored after withContext completes, even if the block throws. Nested calls merge their contexts - inner values override outer values for the same key.
Example:
val requestContext = LogContext(mapOf("requestId" to "req-123"))
val result = LogContextHolder.withContext(requestContext) {
logger.info { "Handling request" }
processRequest() // return value is propagated
}Functions
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Returns the currently active LogContext for the current thread or execution scope. Returns an empty LogContext if none has been set.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.