Re: Dependency management style
I like this idea. > On Jan 8, 2024, at 4:09 AM, Piotr P. Karwasz wrote: > > Hi all, > > Following the discussion in PR#2166, I would like to change the dep > management convention I mentioned in 2022. > > On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz > wrote: >> It would be also nice to synchronise the `pom.xml` of `release-2.x` >> and `master`. Since the main `pom.xml` has about a hundred >> dependencies, what do you think about normalizing them by: >> >> * using BOMs if available (e.g. Jackson), >> * removing the scope from ``: this way there >> will be no difference between BOMs and explicit dependencies. It's >> more verbose, but we won't risk having JUnit in the compile scope. >> * removing exclusions from ``: AFAIK they are >> ignored by Maven. Or we can keep the exclusions as a template for the >> projects. >> * adding a property in the main pom.xml for *each* dependency used >> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on >> how to name these properties would be nice too... >> * sorting dependencies by scope (provided > compile > runtime > >> test), artifactId and groupId. >> >> Since POM style is as personal as code style, I would agree to all >> possible conventions as long as they are coherent. > > This convention seems unnatural to many of our contributors, > especially regarding dependencies that are used by a single module. > > Alternative Maven resolvers have also problems with a centralized dep > management (cf. Issue#1983 for example). > > Therefore I would like to amend the proposition above to state: > > * if a dependency is used by a single module, it is only declared in > that module, > * if a dependency is used by more than one module, it should be > managed in the parent. > > What do you think? > > Piotr > > [1] https://github.com/apache/logging-log4j2/pull/2166 > [2] https://github.com/apache/logging-log4j2/issues/1983
Re: `a.o.l.l.core.parser` package removal
Hi Mikael, On Sun, 7 Jan 2024 at 10:38, Mikael Ståldal 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 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
Re: Dependency management style
+1 On Mon, Jan 8, 2024 at 11:11 AM Piotr P. Karwasz wrote: > Hi all, > > Following the discussion in PR#2166, I would like to change the dep > management convention I mentioned in 2022. > > On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz > wrote: > > It would be also nice to synchronise the `pom.xml` of `release-2.x` > > and `master`. Since the main `pom.xml` has about a hundred > > dependencies, what do you think about normalizing them by: > > > > * using BOMs if available (e.g. Jackson), > > * removing the scope from ``: this way there > > will be no difference between BOMs and explicit dependencies. It's > > more verbose, but we won't risk having JUnit in the compile scope. > > * removing exclusions from ``: AFAIK they are > > ignored by Maven. Or we can keep the exclusions as a template for the > > projects. > > * adding a property in the main pom.xml for *each* dependency used > > (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on > > how to name these properties would be nice too... > > * sorting dependencies by scope (provided > compile > runtime > > > test), artifactId and groupId. > > > > Since POM style is as personal as code style, I would agree to all > > possible conventions as long as they are coherent. > > This convention seems unnatural to many of our contributors, > especially regarding dependencies that are used by a single module. > > Alternative Maven resolvers have also problems with a centralized dep > management (cf. Issue#1983 for example). > > Therefore I would like to amend the proposition above to state: > > * if a dependency is used by a single module, it is only declared in > that module, > * if a dependency is used by more than one module, it should be > managed in the parent. > > What do you think? > > Piotr > > [1] https://github.com/apache/logging-log4j2/pull/2166 > [2] https://github.com/apache/logging-log4j2/issues/1983 >
Dependency management style
Hi all, Following the discussion in PR#2166, I would like to change the dep management convention I mentioned in 2022. On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz wrote: > It would be also nice to synchronise the `pom.xml` of `release-2.x` > and `master`. Since the main `pom.xml` has about a hundred > dependencies, what do you think about normalizing them by: > > * using BOMs if available (e.g. Jackson), > * removing the scope from ``: this way there > will be no difference between BOMs and explicit dependencies. It's > more verbose, but we won't risk having JUnit in the compile scope. > * removing exclusions from ``: AFAIK they are > ignored by Maven. Or we can keep the exclusions as a template for the > projects. > * adding a property in the main pom.xml for *each* dependency used > (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on > how to name these properties would be nice too... > * sorting dependencies by scope (provided > compile > runtime > > test), artifactId and groupId. > > Since POM style is as personal as code style, I would agree to all > possible conventions as long as they are coherent. This convention seems unnatural to many of our contributors, especially regarding dependencies that are used by a single module. Alternative Maven resolvers have also problems with a centralized dep management (cf. Issue#1983 for example). Therefore I would like to amend the proposition above to state: * if a dependency is used by a single module, it is only declared in that module, * if a dependency is used by more than one module, it should be managed in the parent. What do you think? Piotr [1] https://github.com/apache/logging-log4j2/pull/2166 [2] https://github.com/apache/logging-log4j2/issues/1983
