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.
