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. > >>> > >> > >> > > > >
