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.es...@softwareplumbers.com>
wrote:
https://jira.qos.ch/browse/SLF4J-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
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
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
