[
https://issues.apache.org/jira/browse/LOG4J2-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371196#comment-16371196
]
ASF GitHub Bot commented on LOG4J2-2252:
----------------------------------------
Github user remkop commented on the issue:
https://github.com/apache/logging-log4j2/pull/148
Please ignore my previous comment.
On closer inspection, I realized that `MutableLogEvent::getFormat` and
`RingBufferLogEvent::getFormat` currently already return `null`
unconditionally, and return `this` from their `getMessage` method, so current
custom user code already has to deal with `null` values from
`Message::getFormat`.
I'm generally okay with the proposed changes.
I'm not sure that it is a good idea to make the decision on whether to
return `null` or not hinge on whether returning a non-null String would create
garbage. it may be more consistent to always return `null` from `Message`
implementations that do not have embedded curly braces. But the proposed
implementation is also ok.
> Reusable events drop the original format string
> -----------------------------------------------
>
> Key: LOG4J2-2252
> URL: https://issues.apache.org/jira/browse/LOG4J2-2252
> Project: Log4j 2
> Issue Type: Bug
> Reporter: Carter Douglas Kozak
> Priority: Major
>
> MutableLogEvent and RingBufferLogEvent hold references to state from original
> messages, but they currently exclude the value of Message.getFormat().
> I would like to write a custom Layout implementation which is aware of the
> format string and parameters, which doesn't necessarily use the formatted
> message value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
