AlexxeyKa commented on issue #2996:
URL:
https://github.com/apache/logging-log4j2/issues/2996#issuecomment-2369299421
@vy Thanks for your reply.
I agree that using `LOGGER.info("userContext: {}", toJSON(userContext));` is
not an option for two reasons:
1. Serialization still happens in the main thread.
2. The serialized value is embedded in the message – instead of being
handled as a key-value pair for structured logging.
While switching to `Log4jEventBuilder#addKeyValue("userContext",
toJSON(userContext))` could address the second issue (using structured
key-value logging), the first problem remains: the serialization still occurs
on the main thread.
The core of my request is to store the key-values passed via `addKeyValue()`
in the `LogEvent` as a `Map<String, Object>` rather than converting them to a
`ReadOnlyStringMap`. This would allow the layout to handle object
serialization, giving developers the flexibility to define how and when values
are serialized, especially when combined with asynchronous logging.
By default, key-values passed via `addKeyValue()` could still be serialized
using `toString()` and embedded into the message. However, if I want to create
a custom log appender/plugin/layout, I’d like to have the ability to log these
values in a different way.
E.g. in my custom log4j Layout, I want to be able to detect when values were
passed via `addKeyValue()`, so that I can log them differently. This
distinction would enable me to treat key-value pairs in a special way, such as
formatting them for structured logging.
I think this option
> Extend LogBuilder to accept custom KV-pairs
...is a good way, but it’s important that `LogEvent` is also modified to
store these key-value pairs separately.
Regarding `ScopedContext`, will JDK 21 be required?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
