Hi Mikael, On Sun, 7 Jan 2024 at 10:38, Mikael Ståldal <mik...@staldal.nu> wrote: > What about (re)moving the classes which actually depends on Jackson > (AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser, > YamlLogEventParser), but keeping the interfaces (LogEventParser, > TextLogEventParser, ParseException) in log4j-core?
I would prefer to have those interfaces in a separate artifact and include in `log4j-core` only those components that 90% of users need. That said, I don't have an opinion, where this new `log4j-parser` artifact should be. It can be in the main repo, in `l-l-audit`, `l-l-transform`, `l-l-samples` or a separate repo. Right now it is in samples, since its most probable user (Log4j Server) is also there On Sun, 7 Jan 2024 at 10:53, Mikael Ståldal <mik...@staldal.nu> wrote: > Then users or 3rd parties can implement their own parsers if they need to. > > It might be useful to have parsers for some common formats like GELF, > Logstash or RFC-5424, and that can be implemented without using Jackson > if necessary. Do you have some examples of applications that could be interested in mapping log entries to `org.apache.logging.log4j.LogEvent` objects? AFAIK: * most processing tools are happy enough to receive logs in a structured format, regardless of the exact schema used; * I would prefer not to write parsers for unstructured formats (e.g. those from PatternLayout), since it seems very hard to write one without tons of log injection vulnerabilities (e.g. CRLF vulnerabilities). Users that want to automatically process their logs should use structured formats anyway. A niche where such parsers might be useful is parsing logs from server applications like Exim, Dovecot, etc. that are not able to log in JSON. These logs are practically structured logs, but they have their own structure. Log event parsing + Log4j Audit might be useful to provide a light alternative to Crowdsec (which is an extremely slow log parsing/distributed firewall written in Go). Piotr
