[jira] [Commented] (LOG4J2-3344) Add fluent API for MapMessage and structured logging

["Volkan Yazici (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477438#comment-17477438 ] 

Volkan Yazici commented on LOG4J2-3344:
---------------------------------------

This has the potential to be a killer feature for the Log4j API. As a bonus, this is something cannot (easily?) be cloned by competitors – of which many assume a log message is always of type string. I am certainly interested in this venture!

> Add fluent API for MapMessage and structured logging
> ----------------------------------------------------
>
>                 Key: LOG4J2-3344
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3344
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: API
>            Reporter: Matt Sicker
>            Priority: Major
>
> Creating and logging either a MapMessage or a StructuredDataMessage is fairly verbose compared to logging regular strings. The LogBuilder API seems like a natural place to provide an extension here, or some factory methods and builders could be added to the message classes themselves. If a wrapper value is added similar to how [this StructuredArguments API works|https://github.com/logfellow/logstash-logback-encoder/blob/main/src/main/java/net/logstash/logback/argument/StructuredArguments.java] (though not by abusing markers or other workarounds to SLF4J), then key/value pairs could potentially be added as arguments to a ParameterizedMessage or some new message type. Ideally, this API should be useful for writing structured log data to output formats like JSON.
> Using existing functionality, this could be done by adding key/value pairs to the ThreadContext right before logging a message followed by removing those keys from the ThreadContext. This workaround doesn't work well when other code is adding their own keys, and it adds unnecessary overhead when the map is only being used for a single log message.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)