In 2.9-SNAPSHOT, you can use includeNullDelimiter="true" on the layout.
On 2017-08-02 09:23, Jörn Huxhorn wrote:
I started working on the Lilith side of this and I think I’m pretty much done.
To test the new functionality in a sandbox application, I’d now need the ability to
switch JsonLayout, YamlLayout and XmlLayout into a mode were events are terminated
with a 0-byte instead of being separated by “, ".
On 26. July 2017 at 21:14:41, Mikael Ståldal (mi...@apache.org) wrote:
That would make sense.
On 2017-07-26 19:51, Jörn Huxhorn wrote:
Isn’t this supposed to also use 0-byte terminated events in the future?
Because in that case it would make sense to change from String to byte[]
processing.
On 26. July 2017 at 17:49:07, Mikael Ståldal (mi...@apache.org) wrote:
They just need the String version:
https://github.com/apache/logging-log4j-tools/blob/master/log4j-server/src/main/java/org/apache/logging/log4j/server/InputStreamLogEventBridge.java#L100
On 2017-07-26 17:40, Gary Gregory wrote:
What do our XML and JSON server need? Let's make sure we handle those use
cases.
Gary
On Jul 26, 2017 05:30, "Jörn Huxhorn" wrote:
+1
On 26. July 2017 at 13:29:27, Mikael Ståldal (mi...@apache.org) wrote:
Maybe I should remove both the Reader and the InputStream versions,
since they cannot parse multiple log events from a stream, and are thus
not very useful.
On 2017-07-26 10:34, Jörn Huxhorn wrote:
It would maybe be a good idea to get rid of the Reader method
altogether since it mainly
introduces an unnecessary point of failure if the Reader is using an
encoding other than
UTF-8.
Using a FileReader would be an example for this since its limited
c'tors are always using
Charset.defaultCharset().name().
The correct way to create an UTF-8 file reader is the less than
obvious "new InputStreamReader(new
FileInputStream(file), StandardCharsets.UTF_8)”. That’s a very common
mistake.
