[
https://issues.apache.org/jira/browse/LOG4J2-2433?focusedWorklogId=178194&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-178194
]
ASF GitHub Bot logged work on LOG4J2-2433:
------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Dec/18 01:15
Start Date: 22/Dec/18 01:15
Worklog Time Spent: 10m
Work Description: jvz commented on issue #8: LOG4J2-2433 Coroutines
Support
URL:
https://github.com/apache/logging-log4j-kotlin/pull/8#issuecomment-449533982
That sounds better to me!
On Fri, Dec 21, 2018 at 16:47, Raman Gupta <[email protected]> wrote:
> *@rocketraman* commented on this pull request.
> ------------------------------
>
> In
>
log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/ThreadContextContext.kt
>
<https://github.com/apache/logging-log4j-kotlin/pull/8#discussion_r243708005>
> :
>
> > + * logger.info { "..." } // The Thread context contains the
mapping here
> + * }
> + * ```
> + *
> + * Note, that you cannot update Thread context from inside of the
coroutine simply
> + * using [ThreadContext.put]. These updates are going to be lost on the
next suspension and
> + * reinstalled to the Thread context that was captured or explicitly
specified in
> + * [contextMap] when this object was created on the next resumption.
> + * Use `withContext(ThreadContext()) { ... }` to capture updated map of
Thread keys and values
> + * for the specified block of code.
> + *
> + * @param contextMap the value of [Thread] context map.
> + * Default value is the copy of the current thread's context map that is
acquired via
> + * [ThreadContext.getContext].
> + */
> +public class ThreadContextContext(
>
> I struggled with the name. It is actually a Kotlin coroutines "Context",
> for a Log4j "ThreadContext". Calling it ThreadContextHolder doesn't seem
> quite right either, as it does a bit more than just hold the log4j
> ThreadContext. How about CoroutineThreadContext?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
>
<https://github.com/apache/logging-log4j-kotlin/pull/8#discussion_r243708005>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AAwS68B9B66XTsrM_789sRS_34xlNFxEks5u7WT2gaJpZM4ZJSG8>
> .
>
--
Matt Sicker <[email protected]>
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 178194)
Time Spent: 1h (was: 50m)
> Support MDCs with Kotlin coroutines
> -----------------------------------
>
> Key: LOG4J2-2433
> URL: https://issues.apache.org/jira/browse/LOG4J2-2433
> Project: Log4j 2
> Issue Type: New Feature
> Components: Kotlin API
> Affects Versions: Kotlin 1.0.0
> Reporter: Raman Gupta
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Create support for log4j2 MDC when used with Kotlin coroutines. Since
> coroutines do not guarantee which underlying thread is executing code after a
> continuation, a standard ThreadLocal is not sufficient to keep the MDC
> context.
> Kotlin coroutines have a mechanism by which "coroutine local" data can be
> stored. See the reference implementation for SLF4J here:
> https://github.com/Kotlin/kotlinx.coroutines/tree/master/integration/kotlinx-coroutines-slf4j
> We should implement an optional native module to add support for log4j2 MDC
> using the same pattern, that does not require having SLF4J and the
> slf4j-log4j2 implementation on the classpath.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
