I have a number of components, all of which get an XLogger directly via XLoggerFactory. Shared components are deployed in both JEE6 and JEE7 application servers (not my choice…) as plugins to 3rd party applications (so I have little control over the stack). Some components are also deployed in a Spring Boot 1.5 application, where I depend on spring-boot-starter-logging. I try to use logback as a back end where possible. The issue is mostly a problem in the Spring Boot app because that’s where I’m slinging the most Json.
The app is deployed at a bank (they seem to regard any technology as dangerously new right up until they get the first end-of-life notice) so I’m not sure embedding the 2.0.0 alpha would pass review even if I could get it working with the rest of the stack. > On Feb 20, 2020, at 11:55 AM, Ceki <c...@qos.ch> wrote: > > Hi Jonathan, > > The bug is duly noted. May I ask via which stack you are invoking XLogger? > > Thank you, > -- > Ceki > > On 20.02.2020 14:26, Jonathan Essex wrote: >> 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 > > -- > -- > Ceki Gülcü > _______________________________________________ > slf4j-dev mailing list > slf4j-dev@qos.ch > http://mailman.qos.ch/mailman/listinfo/slf4j-dev _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
