Not a lot of traffic on this mailing list... is there a better place to raise this? On 2/11/20, 7:25 AM, "Jonathan Essex" <jonathan.essex@softwareplumbers.com> wrote: https://jira.qos.ch/browse/SLF4J-421?page=com.atlassian.jira.plugin.system.i... Does anyone have time to review/discuss my PR for SLF4J-421? It’s really a horrible bug as if you are outputting any JSON it tends to produce realistic-looking log messages which also happen to be utterly misleading. I went down a 2-day rabbit hole looking in totally the wrong place to resolve a problem because my log data was telling me that the application was doing something which was both wrong and plausible. In my view, XLogger is not fit for purpose at all and should be removed or marked deprecated until this issue is resolved. I couldn’t believe my eyes when I found this case has been open for over two years. Unfortunately now XLogger is thoroughly embedded in 8 of my components and the effort to replace it would be considerable. I have submitted a PR with a unit test, but the solution does require discussion, as to avoid making potentially breaking changes it seems necessary to add to the API of MessageFormatter. I have: 1) Added public methods to MessageFormatter which will ‘escape’ any formatting delimiters in the output message 2) Modified XLogger and LoggerWrapper to use the escaping versions of the MessageFormatter methods log.error("{},{}", foo, "[{}]") will now produce: foo,[\{}] instead of foo,[foo] I note that I don’t think it’s possible to create the exact desired behavior (output foo,[{}]) without changing the behavior of the standard message formatter methods to remove escape characters (so log.error(“\{}”,”a”) would produce {} instead of \{} ). This latter change is defensible but since it might alter existing behavior I thought it best left for now. Regards Jon. Thanks Jon