rocketraman commented on issue #71: URL: https://github.com/apache/logging-log4j-kotlin/issues/71#issuecomment-1997613964
> I think this is related to [[apache/logging-log4j2#2213](https://github.com/apache/logging-log4j2/issues/2213)]. @vy It seems so, but I'm unsatisfied by the answers in the [discussion](https://github.com/apache/logging-log4j2/discussions/2214). Let me see if I can illustrate my use case with a generic example. Assume we have this setup: ``` class T { val log = logger() val r: R fun doSomethingInThread() { r.doSomethingOnResource() log.info { "bar" } } } class R { val log = logger() fun doSomethingOnResource() { log.info { "foo" } } } ``` `T` represents some kind of thread. It could be an HTTP request thread for example. So we have some diagnostic context related to that thread, say a request id. `R` represents some kind of resource used by `T`. It could be a state machine or a physical resource or whatever. There is some diagnostic context related to this resource, say a resource name or id. Inside `doSomethingOnResource` when logging "foo", both the thread and resource diagnostic contexts are relevant. However, inside `doSomethingInThread` i.e. the "bar" log, only the thread context is relevant. If `doSomethingOnResource` were to set the context for the resource in the `ThreadContext` before the `foo` log, then the `bar` log would also show the resource context, which would be incorrect. The thread or coroutine attached context works well for `T` but doesn't work well at all for `R`, which is used within the thread of `T`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
