ppkarwasz opened a new pull request, #2381: URL: https://github.com/apache/logging-log4j2/pull/2381
The semantics used to determine the `Throwable` attached to a log event changed in Logback 1.1.0 (in the fix to [LOGBACK-873](https://jira.qos.ch/browse/LOGBACK-873)). When there are not enough arguments to the log call to fill both the throwable field and the placeholders contained in the message pattern, Logback 1.1.0 and later prefer to fill the throwable field and leave some placeholders empty. Log4j Core does the opposite choice: it first fills all the placeholders and only fills the throwable field if there is something left. This change allows `log4j-slf4j-impl` and `log4j-slf4j2-impl` users to switch between the two behaviors by setting the property `log4j2.messageFactory` to: ``` org.apache.logging.slf4j.message.ThrowableConsumingMessageFactory ``` In this PR two choices have been made: - the message factory is only included in `log4j-slf4j-impl` and `log4j-slf4j2-impl`, since it should be mostly required by Logback users during a transition period. Note that Logback's and Log4j's semantics to deal with throwables agree whenever enough arguments are provided. In a second step users can modify their code using openrewrite/rewrite-logging-frameworks#141, so that it behaves in the same way in Logback and Log4j Core out-of-the-box. However I can also create a new `log4j-message` artifact for this. - no **garbage-free** version of this factory is provided. SLF4J creates temporary arrays whenever **more than 2** arguments are provided. I believe that an additional creation of a `ParameterizeMessage` instance does not make a difference. Closes #2363 -- 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]
