Hi Chia-Ping, Yes in 4.0.0 we will only provide log4j2 configuration files. We will still support log4j.properties files for compatibility but that will print a warning when these are used.
However my question is about the format of our log4j2 files. Currently in the PR we are using the "properties" format (log4j2.properties). But as pointed by Piotr (from the Apache Logging PMC), log4j2 has a hierarchical structure which does not translate well into the properties format, so configuration file in this format have many quirks. Instead he suggested using XML, JSON or YAML in our example files (so log4j2.xml or log4j2.json or log4j2.yaml) as these are the preferred formats now. David, Viktor and myself have expressed our preference toward adopting YAML for our log4j2 configuration files. I'm wondering if that's enough consensus, or if people want to discuss this further, or even want a vote? Thanks, Mickael On Mon, Nov 18, 2024 at 1:52 PM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > hi, Mickael > > I'm +1 for using the log4j2 format. Otherwise, it's odd for users to see > deprecation warnings about log4j.properties when using our example files. > > Best, > Chia-Ping > > > > Mickael Maison <mickael.mai...@gmail.com> 於 2024年11月18日 週一 下午7:33寫道： > > > Hi, > > > > The log4j2 migration PR is pretty much ready to be merged and the > > first deadlines for 4.0.0 is approaching fast. > > I think we should decide which format to use in our example log4j2 > > files to avoid having to update the format shortly after 4.0.0. > > > > This point is not really covered by KIP-653: Upgrade log4j to log4j2. > > Do we want another KIP and vote or is a consensus emerging? > > > > Thanks, > > Mickael > > > > On Wed, Nov 6, 2024 at 10:47 AM Mickael Maison <mickael.mai...@gmail.com> > > wrote: > > > > > > Hi, > > > > > > I think our example log4j2 file should be as idiomatic as possible. If > > > YAML is now the recommended format, then it makes sense to adopt it. I > > > would also do this directly in 4.0.0. > > > > > > Like David, one concern when adding extra dependencies is CVEs. YAML > > > is a widely used format and the libraries are actively maintained so I > > > think it's acceptable. > > > > > > In my opinion, the configuration format for Kafka is a completely > > > orthogonal issue. If people want to adopt YAML this can be done in a > > > separate discussion. I don't see issues with using YAML for > > > configuring log4j2 and properties for Kafka. > > > > > > Thanks, > > > Mickael > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2024 at 5:47 PM Piotr P. Karwasz > > > <pi...@mailing.copernik.eu> wrote: > > > > > > > > Hi Viktor, > > > > > > > > On 31.10.2024 10:19, Viktor Somogyi-Vass wrote: > > > > > I could see a transition for Kafka configs too to YAML. It's widely > > used in > > > > > other projects as well and for Kafka too it would make sense to > > group them > > > > > for instance by log, storage, networking, security etc.. It > > definitely > > > > > has an advantage that we could move to a more well defined structure > > and > > > > > away from these long prefixes which are very cumbersome in some > > places. > > > > > Perhaps 4.0 would have been a good candidate but given that we should > > > > > provide backward compatibility anyway, later is good too. > > > > > > > > To migrate the configuration from Java Properties to YAML and maintain > > > > BC, you can use `jackson-dataformat-properties`. This definitively can > > > > be done in a minor release. > > > > > > > > [1] > > > > > > https://github.com/FasterXML/jackson-dataformats-text/blob/master/properties/README.md > > > > > > > > > 4. Data bindings and parsers are common sources of CVEs. It looks > > like > > > > > Snakeyaml is no exception ( > > > > > https://www.cvedetails.com/version-list/0/66013/1/), though it > > doesn't look > > > > > much worse than Jackson. Just to point out, this will add a bit of > > > > > dependency overhead as we keep up with security patches. > > > > > > > > > > It's a good point about CVEs. I haven't seen it on the dev list but > > were > > > > > there any conversations about enabling dependabot version updates? > > With > > > > > automatic dependabot PRs we could get fixes in as soon as it opens > > the PR. > > > > > > > > I don't know how it works in Gradle, but with Maven we don't get > > > > Dependabot PRs for transitive dependencies such as SnakeYAML. Since the > > > > dependency is not present in the `pom.xml`, its version can not be > > > > updated. Dependabot might be able to create alerts in the "Security" > > tab > > > > though. > > > > > > > > Since Log4j is a library without an executable distribution, it is not > > > > guaranteed that a new version of Log4j will be released each time a > > > > vulnerability in SnakeYAML is discovered and that vulnerability is > > > > exploitable in Log4j Core. It does not make much sense to make a new > > > > release just to upgrade a number in `pom.xml`. > > > > > > > > Until VEX-es can be created automatically, the only way I can think of > > > > to help the Kafka team with CVEs in transitive dependencies is a manual > > > > process: > > > > > > > > * You mark `jackson-dataformat-yaml` with a comment like "Used by Log4j > > > > Core". > > > > > > > > * If a CVE is reported against that artifact or its dependencies, you > > > > open an issue in Log4j[2], so we can advise on the exploitability of > > the > > > > CVE. > > > > > > > > * With that information you can decide whether to release a new Kafka > > > > version or not. > > > > > > > > Piotr > > > > > > > > [2] https://github.com/apache/logging-log4j2/issues > > > > > > > > > >
