hi Ismael thanks for all your response.
> All that said, I am not actually sure we can do what I described above while maintaining the compatibility required by a minor release. Excuse me, are your concerns related to version matching, as discussed in [0]? If so, I concur that this represents a compatibility issue, and the target version for this change should be 5.0. Additionally, there was a related discussion previously documented in [1]. While we have not strictly enforced version matching during prior SLF4J updates, this KIP provides an opportunity to establish guidelines for upgrading sl4fj that have direct compatibility implications. [0] https://www.slf4j.org/faq.html#compatibility [1] https://github.com/apache/kafka/pull/16324#discussion_r1644671854 To Teng Could you please revise the KIP according to following benefit? > The key benefit of this KIP is that you can add new logging backends and select it via a config. This is how most pluggable things work. But it is *not* how slf4j 1.x works. slf4j 1.x requires you to *remove* the default logging library picked by the project as well. That's much more intrusive. Best, Chia-Ping Ismael Juma <m...@ismaeljuma.com> 於 2025年3月20日 週四 上午8:10寫道： > Hi Chia-Ping, > > I don't think we're in the business of shipping multiple logging libraries. > Here's my take: > > 1. We should pick one logging library for services/servers, ship it and > include a configuration file for it. > 2. For clients, we leave it to the users to select the logging library - > clients run alongside applications and it's desirable to use the same > logging library for both (if we were starting from scratch, we may have > decided to also include our default logging library for clients as well, > but it's hard to make that change now). > 3. For the cases where users want to use a different logging library for > services/servers (perhaps because they have standardized on a different > logging library), they would have to add the additional jar to the > classpath and change the relevant logging config. This is no different than > adding a different authorizer or any other pluggable component. > > The key benefit of this KIP is that you can add new logging backends and > select it via a config. This is how most pluggable things work. But it is > *not* how slf4j 1.x works. slf4j 1.x requires you to *remove* the default > logging library picked by the project as well. That's much more intrusive. > > All that said, I am not actually sure we can do what I described above > while maintaining the compatibility required by a minor release. > > Ismael > > On Wed, Mar 19, 2025, 2:03 PM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > hi Ismael > > > > > but they must also add whichever logging library they want to use. > > > > If users are required to modify JAR files to alter the SLF4J provider, > the > > value of this KIP is significantly diminished. I believe the primary > > benefit of this KIP lies in enabling users to configure a system property > > for SLF4J provider changes without JAR modifications. Furthermore, by > > managing all SLF4J and provider JARs within Kafka, we can ensure SLF4J > > version updates without compatibility concerns, as we can guarantee > > provider JAR consistency with the SLF4J version in the distribution. > > > > Best, > > Chia-Ping > > > > Ismael Juma <m...@ismaeljuma.com> 於 2025年3月19日 週三 下午12:00寫道： > > > > > Hi TengYao, > > > > > > It's a bit difficult to review the KIP. I don't follow most of the > > > motivation. The only one that I follow is: > > > > > > "Our current build configuration employs fragile dependency management > > > tricks to handle SLF4J backends. We can eliminate these brittle build > > > mechanisms by transitioning to explicit provider dependencies after > > > upgrading to 2.0." > > > > > > Additionally, I don't think we should do the following: > > > > > > "Add other popular slf4j backend binding provider dependencies." > > > > > > A reasonable approach, in my opinion, would be: > > > > > > 1. Include the log4j2 dependency with the server modules and not > include > > > them with the client modules. > > > 2. Automatically configure the log4j2 dependency for the server > modules. > > > Users can override them via the system property, but they must also add > > > whichever logging library they want to use. > > > 3. Somehow configure slf4j 2.x to work like 1.x out of the box for the > > > client module (for compatibility reasons). > > > > > > But I don't know if `3` is possible. If `3` is not possible, I don't > see > > > how we can make this a compatible change. > > > > > > Ismael > > > > > > On Tue, Mar 18, 2025 at 7:41 PM TengYao Chi <kiting...@gmail.com> > wrote: > > > > > > > Hello everyone, > > > > > > > > I want to bump this thread manually. > > > > Any feedback or vote would be appreciated. > > > > > > > > Best, > > > > TengYao > > > > > > > > TengYao Chi <kiting...@gmail.com> 於 2025年3月10日 週一 上午11:47寫道： > > > > > > > > > Hello guys, > > > > > I would like to remind you in the vote thread that the KIP has been > > > > > updated, and I apologize for repeating it. > > > > > I have taken over this KIP from Muralidhar. > > > > > Since the original content is outdated as 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 > > > > > > > > > > Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 > 2024年9月24日 > > 週二 > > > > > 上午5:09寫道： > > > > > > > > > >> Hi, > > > > >> > > > > >> I wanted to gently follow up on this thread in case anyone has any > > > > >> thoughts > > > > >> or would like to take a look. > > > > >> > > > > >> Thanks, > > > > >> Murali > > > > >> > > > > >> On Mon, Sep 16, 2024 at 10:23 AM Muralidhar Basani < > > > > >> muralidhar.bas...@aiven.io> wrote: > > > > >> > > > > >> > Thanks Chia. > > > > >> > > > > > >> > I have updated KIP with this quote, in the migration plan > section. > > > > >> > > > > > >> > Thanks, > > > > >> > Murali > > > > >> > > > > > >> > On Sun, Sep 15, 2024 at 3:30 PM Chia-Ping Tsai < > > chia7...@gmail.com> > > > > >> wrote: > > > > >> > > > > > >> >> > > > > >> >> > Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 > > > > 2024年9月15日 > > > > >> >> 晚上9:02 寫道： > > > > >> >> > > > > > >> >> > With this, I think, users don't have to make any explicit > > changes > > > > in > > > > >> >> their > > > > >> >> > code, if their provider is reload4j. And if it's a different > > > > provider > > > > >> >> (like > > > > >> >> > logback, log4j), they would have to upgrade that to match it > > with > > > > >> slf4j. > > > > >> >> > > > > >> >> If upgrading the matched provider is the only explicit change > and > > > we > > > > >> >> expect users have responsibility to keep consistent version > when > > > > using > > > > >> >> other providers , could we write it down to the KIP? > > > > >> >> > > > > >> >> That means we will update slf4j without KIP in the future > except > > > for > > > > >> >> specific reason. > > > > >> >> > > > > >> >> Best, > > > > >> >> Chia-Ping > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
