Hi everyone, >From my experience, it has been quite challenging to understand and transform the .properties file from log4j 1 to log4j 2, as the properties format is fairly flat and difficult to understand. In comparison, YAML is more structured, easier to read, and widely used. I would like to +1 for using YAML properties instead. If a KIP is required, I am willing to prepare one.
Best, TengYao Mickael Maison <mickael.mai...@gmail.com> 於 2024年11月18日 週一 下午9:35寫道： > 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 > > > > > > > > > > > > > >
