Whoops... yes, of course. false. m) I'd use the byte[] method in Lilith.
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. On 26. July 2017 at 09:50:21, Mikael Ståldal (mi...@apache.org) wrote: > I guess you mean: > > this.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); > > Out of curiosity, which of the methods would you use? Reading > InputStream, Reader, String or byte[] ? > > > On 2017-07-25 23:24, Jörn Huxhorn wrote: > > Hey Mikael, > > sorry for the slow response time. > > > > GMail thought that - of all the dev mailing list mails - this specific mail > > looked like > spam. I just found it hidden in the spam folder... > > > > The API looks good to me, assuming that I’ll be fine with the default c’tor > > versions of > Log4jJsonObjectMapper, Log4jYamlObjectMapper and Log4jXmlObjectMapper. > Otherwise > I'd need matching c’tors in the respective LogEventParser implementations. > > > > It may make sense to add this line to the ObjectMapper c'tors: > > this.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, true); > > > > This would make parsing less fragile. If new fields are added in future > > log4j versions > then previous versions could still read the event, just without filling the > new field. > > Another example would be StackTraceElement getting new fields in Java 9, > > making it > possible to still parse Java 9 events in Java 8. > > > > Disclaimer: I didn’t test this. I usually annotate specific Mixins with > > "@JsonIgnoreProperties(ignoreUnknown=true)” > where it makes sense. This may be way *too* lenient. > > > > It isn’t too critical either and is just meant for your consideration. I’m > > fine with > the parser implementations regardless of such a change. > > > > Thanks a lot for providing an official parser API! > > > > Cheers, > > Jörn. > > > > > > On 25. July 2017 at 09:51:56, Mikael Ståldal (mi...@apache.org) wrote: > >> Jörn Huxhorn, would the API in Git branch LOG4J2-1986 work for you? > >> > >> On 2017-07-22 22:49, Mikael Ståldal wrote: > >>> Work in progress in Git branch LOG4J2-1986. > >>> > >>> On 2017-07-22 22:31, Mikael Ståldal wrote: > >>>> Yes, I am putting it in its own Java package. > >>>> > >>>> > >>>> On 2017-07-22 22:13, Gary Gregory wrote: > >>>>> Should this API sit in its own package? > >>>>> > >>>>> On Jul 22, 2017 11:41, "Mikael Ståldal" wrote: > >>>>> > >>>>>> I'll give it a shot: > >>>>>> > >>>>>> https://issues.apache.org/jira/browse/LOG4J2-1986 > >>>>>> > >>>>>> > >>>>>> On 2017-07-22 20:28, Ralph Goers wrote: > >>>>>> > >>>>>>> Yes, that is a good idea. Probably XML and YAML as well. > >>>>>>> > >>>>>>> Ralph > >>>>>>> > >>>>>>> On Jul 22, 2017, at 11:21 AM, Mikael Ståldal wrote: > >>>>>>>> > >>>>>>>> But here we have a concrete use case: a third-party tool, Lilith, > >>>>>>>> needs > >>>>>>>> to parse log events from our JsonLayout. (Our SocketServer in > >>>>>>>> log4j-server > >>>>>>>> have the same need, and it uses this class.) > >>>>>>>> > >>>>>>>> Should we provide a public API in log4j-core for doing so, which > >>>>>>>> Lilith, > >>>>>>>> our SocketServer, and possibly others (Chainsaw maybe?) can use? > >>>>>>>> Maybe such > >>>>>>>> public API should be a facade around this which hides the fact > >>>>>>>> that we use > >>>>>>>> Jackson. > >>> > >> > >> > > > >
