I don’t think anyone passing an escape sequence expects it to show up as a string. So I would be good with your proposed solution. That method should be part of core so we can modify all Layouts to use it.
Ralph > On Sep 13, 2021, at 12:29 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > > I had addressed this issue in 2020 July in a post titled "String parameter > with escapes (Was: Testing Json Template Layout)" > <https://mail-archives.apache.org/mod_mbox/logging-dev/202007.mbox/%3cCAP7pH7uWjjn=ZDCeejmqMQHgbFiTV=23J9D3n=whfndb0is...@mail.gmail.com%3e>. > For one, *the issue is not specific to JTL*, but applies to almost every > layout accepting a parameter to be emitted along with the normal output. > Back then, the discussion focused on the null (\0) character needed by > SocketAppender for GELF layout in JTL. In the post, I suggested adding > something similar to `translateEscapes()` of Java 13. This would allow > users to pass escape characters with any string literal in any > configuration format; XML, YAML, properties, etc. Contrasting this with > your proposal for treating certain special inputs (e.g., "null", "Form > Feed") differently, for me, is not different than implementing a > `translateEscapes()`. I personally think this is even worse, since we > introduce a new syntax, whereas the former sticks to the standard Java > string syntax. > > In conclusion, I propose adding a `translateEscapes()` clone and using that > to read `eventDelimiter` and deprecating `nullEventDelimiterEnabled`, since > `nullEventDelimiterEnabled` will simply translate to setting > `eventDelimiter` to `\0`. This breaks the backward compatibility of > `eventDelimiter`, since there might be users out there who set their > `eventDelimiter` to `\t\r\n` and was expecting to get that string literal > as is. Yet, given the relatively recent introduction of the plugin, I think > we can take this risk. > >> On Mon, Sep 13, 2021 at 6:14 AM Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >> I have been working on getting a configuration that works with filebeat >> going again and have been >> trying to change the line delimiter so I could avoid doing the multiline >> crap. I first configured >> eventDelimiter=“\f” since filebeat supports that as a replacement for >> newline. Except no matter >> how hard I tried I couldn’t get filebeat to log anything to stdout. >> >> I spent hours looking at it before I finally realized that the logs being >> written actually had “\f” in >> the string instead of a form feed character. It seems that XML must be >> passing in the value >> treating the “\” as if it is escaped. To remedy this the only solution I >> could come up with was >> >> <JsonTemplateLayout eventTemplateUri="classpath:template.json" >> locationInfoEnabled="true"> >> <eventDelimiter>…</eventDelimiter> >> </JsonTemplateLayout> >> It seems that XML doesn’t allow a form feed character specified that way. >> This caused filebeat >> to start recognizing the log events. I would suggest that we may want to >> change eventDelimiter >> to accept enum names instead of or in addition to characters, which is >> what filebeat does. So >> one could specify eventDelimiter=“Form Feed”. >> >> Ralph
