Hi Federico, > - I would expand the motivation section rather than linking to the discussion
I just reviewed it, and I think we could remove this reference since it doesn't provide much value to this KIP. >- I think we should now update the `log4j2.properties` reference to `log4j2.yaml` Thanks for pointing that out. I have fixed it. Best, TengYao Federico Valeri <fedeval...@gmail.com> 於 2025年3月25日 週二 下午6:25寫道： > Hi TengYao, this change makes sense for a major release. > > Some comments: > - I would expand the motivation section rather than linking to the > discussion > - I think we should now update the `log4j2.properties` reference to > `log4j2.yaml` > > On Mon, Mar 10, 2025 at 7:36 AM TengYao Chi <kiting...@gmail.com> wrote: > > > > Hi Ismael > > > > Thanks for pointing this out. > > I have just updated the "Compatibility, Deprecation, and Migration Plan" > > section and indicated that we should only introduce this change if we are > > sure the compatibility isn't broken. > > > > Please take a look. > > > > Best, > > TengYao > > > > > > Ismael Juma <m...@ismaeljuma.com> 於 2025年3月10日 週一 下午12:51寫道： > > > > > Thanks for updating the KIP. A comment below: > > > > > > As we introduce this change in major version 4.1.0, since we provide > the > > > > backend binding dependencies, users should be able to upgrade their > > > backend > > > > dependencies. > > > > > > > > > 4.1 is a minor version (not major version). So, this KIP is only > > > acceptable in 4.1.0 if we can ensure it doesn't break existing users. > > > Otherwise, it has to wait for 5.0.0. > > > > > > Can you please clarify the KIP with this additional context? > > > > > > Ismael > > > > > > > > > On Sun, Mar 9, 2025 at 8:42 PM TengYao Chi <kiting...@gmail.com> > wrote: > > > > > > > Hello guys, > > > > I have taken over this KIP from Muralidhar. > > > > Given that the original content is outdated since the logging > framework > > > has > > > > been widely changed, I have updated the content of the KIP. > > > > Please take a look and share your thoughts. > > > > > > > > Best Regards, > > > > TengYao > > > > > > > > TengYao Chi <kiting...@gmail.com> 於 2025年2月23日 週日 下午3:19寫道： > > > > > > > > > Hi Muralidhar, > > > > > > > > > > Thanks for the KIP. > > > > > Since we have migrated to log4j2, the KIP content must also be > updated. > > > > > > > > > > Best Regards, > > > > > TengYao > > > > > > > > > > > > > > > Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 > 2024年9月10日 週二 > > > > > 下午1:21寫道： > > > > > > > > > >> Hi, > > > > >> > > > > >> I assume there are no concerns. Will start a voting thread. > > > > >> > > > > >> Thanks, > > > > >> Murali > > > > >> > > > > >> On Fri, Sep 6, 2024 at 2:45 PM Muralidhar Basani < > > > > >> muralidhar.bas...@aiven.io> > > > > >> wrote: > > > > >> > > > > >> > Hi all, > > > > >> > > > > > >> > Now that we are close to 4.0, bringing up this discussion again. > > > > >> > > > > > >> > Do we want to include any other providers, and as for now we > have > > > only > > > > >> > reload4j binding in our dependencies. > > > > >> > We can always provide support for others later. > > > > >> > > > > > >> > Mainly upgrading slf4j to 2.x in 4.0.0 is a primary motive for > this > > > > kip. > > > > >> > > > > > >> > Thanks, > > > > >> > Murali > > > > >> > > > > > >> > On Thu, Jul 4, 2024 at 9:58 PM Chia-Ping Tsai < > chia7...@gmail.com> > > > > >> wrote: > > > > >> > > > > > >> >> > > > > > >> >> > 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 > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> > > > > > >> > > > > > > > > > > > > >
