Hi
Thanks all for the answers.
I actually did some debugging and changed to the thread context data on the
log event around the time for the first reply (when i saw that the log
event was constructed before passing it to the async logger). The reason
for using the lookup and not only %X is that i
Your assumption is correct, but there is a way to avoid the problem. The issue
is that, as one might expect, the ThreadContext is thread specific. So when the
pattern is resolved it will be on the thread where the event is to be written,
not the thread that called the logging method.
You can av
AFAIC, your reasoning on why m:testkey not working is correct. Why don't
you create your own PatternConverter rather than using a custom lookup?
Additionally, if your log sink accepts JSON, you can introduce a custom
resolver to JsonTemplateLayout too -- though note that this feature will be
avail
Hi!
We are using different appenders with a pattern layout that both read
values from ThreadContext using %X and through a custom lookup that
internally access the ThreadContext
If we use a pattern such as "%X{testkey} $${m:testkey} %m" (the lookup
assigned to prefix m access the same key from th
