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
