That’s what I meant with too lenient. It was probably a bad idea.
Might make more sense to think about which Mixins, if any, should get a
@JsonIgnoreProperties(ignoreUnknown=true) annotation… but that is unrelated to
the general parsing API. I kind of derailed the topic because this really
doesn’t need an immediate decision right now.
On 26. July 2017 at 13:32:28, Mikael Ståldal (mi...@apache.org) wrote:
> A slightly related question, what should the parser do about missing
> properties?
>
> Currently it is so lenient that it will successfully parse an empty JSON
> object "{}" and just assign null (or other default values) to all fields.
>
>
> 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.
>
