A solution that involves a warning and classpath ordering doesn't meet the bar for me. Good clarification though.
Ismael On Thu, Mar 20, 2025 at 8:37 AM Farid Zakaria <fzaka...@confluent.io.invalid> wrote: > AFAIR SLF4J you don't have to remove the other backends; merely make > sure yours is first on the CLASSPATH list :P > (SLF4J pre 2.0 would always emit a warning that it found 2+ StaticBinders) > > Interestingly, you could still whatever backend (i.e. Log4J) and pipe > it through to another backend via another appender. > This is what SLF4J refers to bridges -- although you have to be sure > not to create a circular loop. > > Then there is something also general like syslog. > > On Thu, Mar 20, 2025 at 1:15 AM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > > 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 > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >
