OK, everything works for me with 2.9-SNAPSHOT. I can receive JSON, YAML and XML events just fine.
I had the following error while building: [ERROR] Failed to execute goal on project log4j-core-its: Could not resolve dependencies for project org.apache.logging.log4j:log4j-core-its:jar:2.9-SNAPSHOT: Could not find artifact org.apache.logging.log4j:log4j-server:jar:tests:2.9-SNAPSHOT in apache.snapshots (https://repository.apache.org/snapshots), try downloading from https://logging.apache.org/log4j/2.x/download.html -> [Help 1] That wasn’t a serious problem for me since I only need API and core. But I wanted to inform you about this issue since building log4j worked fine for me just a few days ago. I’m sure it worked at d3b722083b8f21ea105a4f01132f08b373cb401e and I think it also worked at b96f5220dbebf6e0a4fb9f7da07c3a9d7d443418 Cheers, Jörn. On 3. August 2017 at 13:30:24, Mikael Ståldal (mi...@apache.org) wrote: > Yes, that test is known to be unstablle. > > Just build with -DskipTests > > > On 2017-08-03 11:24, Jörn Huxhorn wrote: > > I get test failures building against HEAD > > (3ac727026f295941fe71a34d6c80afc242f38c0f). > > > > Environment: > > $ mvn -version > > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; > > 2017-04-03T21:39:06+02:00) > > Maven home: /Users/huxi/.sdkman/candidates/maven/current > > Java version: 1.8.0_144, vendor: Oracle Corporation > > Java home: > > /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: “mac" > > > > Test failure: > > ------------------------------------------------------------------------------- > > > > Test set: > > org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest > > > > ------------------------------------------------------------------------------- > > > > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.518 s <<< > > FAILURE! > - in > org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest > > > testRollingFileAppenderWithReconfigure(org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest) > > > Time elapsed: 2.518 s <<< FAILURE! > > java.lang.AssertionError: > > > > Expected: is <2> > > but: was <3> > > at > > org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest.testRollingFileAppenderWithReconfigure(RollingAppenderDirectWriteWithReconfigureTest.java:68) > > > > > > > > > > > > On 2. August 2017 at 11:30:47, Mikael Ståldal (mi...@apache.org) wrote: > >> 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. > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >
