> > Or do we also provide other binding jars for logback, log4j, simple etc ?
yep, that is a solution which kafka can have strong dependencies on those, but we need to reach the consensus about "which" providers should be included Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 2024年7月5日 週五 上午3:50寫道： > Hi Chia, > Thank you for dropping by on this. > > I have updated both the discussion thread and the Compatibility section > partly. But I would like to discuss a bit more about this and update. > > 3. how to keep the compatibility of updating slf4j version in the future? > According to slf4j compatibility ( > https://www.slf4j.org/manual.html#compatibility), users need to update > their binding version after we update the slf4j-api version. That will be a > trouble as we have to file KIP every time in updating slf4j-api. Including > all binding jars in kafka is a solution, as we can take control over all > binding jars. WDYT? > Indeed, it is not ideal to file a kip always, and ship the upgraded > slf4j-api jars. > I like the approach of providing all binding jars within kafka, however I > see we have only reload4j backend in our dependencies, or I could be wrong. > So just providing a compatible reload4j with it should be ok ? > Or do we also provide other binding jars for logback, log4j, simple etc ? > > Thanks, > Murali > > On Thu, Jul 4, 2024 at 8:04 PM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > hi Muralidhar > > > > thanks for writing the KIP. Please take a look at following comments: > > > > 1. please update the Discussion thread. it has incorrect link > > > > 2. please complete the section "Compatibility, Deprecation, and Migration > > Plan". We had a good discussion in the PR ( > > https://github.com/apache/kafka/pull/16324#discussion_r1643359783). > > > > 3. how to keep the compatibility of updating slf4j version in the future? > > According to slf4j compatibility ( > > https://www.slf4j.org/manual.html#compatibility), users need to update > > their binding version after we update the slf4j-api version. That will > be a > > trouble as we have to file KIP every time in updating slf4j-api. > Including > > all binding jars in kafka is a solution, as we can take control over all > > binding jars. WDYT? > > > > Best, > > Chia-Ping > > > > Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 2024年7月2日 週二 > > 上午3:30寫道： > > > > > Hello, > > > > > > Regarding KIP-1064 [0], I would like to start a discussion on upgrading > > > slf4j to 2.x, which is currently at 1.7.36, and with an option to > > > provide slf4j provider in run class. > > > > > > This is also discussed in jira [1] and git pr [2], and thought we > should > > > have a kip. > > > > > > Please note this kip is intended from kafka 4.0. > > > > > > [0] - > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1064%3A+Upgrade+slf4j+to+2.x > > > [1] - https://issues.apache.org/jira/browse/KAFKA-16936 > > > [2] - > https://github.com/apache/kafka/pull/16324#discussion_r1644295632 > > > > > > Thanks, > > > Murali > > > > > >
