+1 to the upgrade I agree with both the benefits we get from the upgrade. This will also help reduce the vulnerability count for the application that has Flink submodules as a dependency. To resolve the similar issue in FKO we currently excluded the log4j-slf4j-impl and overrode it with 2.0.18: https://github.com/apache/flink-kubernetes-operator/pull/1170 This would help resolve similar issues on other modules as well when we move to build with 2.4.
Also, given that the time for the connectors to move to build with 3.0 is still quite far off, it would increase the count of CVEs we have with 1.7. Therefore, I would be inclined to implement the fix in 2.4 rather than waiting for 3. On Thu, Sep 24, 2026 at 5:35 PM Piotr Przybylski <[email protected]> wrote: > Hi all, > > I would like to propose upgrading the slf4j-api that Flink bundles in > flink-dist.jar from 1.7 to a current 2.x release. Personally, I would like > for this to land in a minor release. > > I see two main benefits to this upgrade: > 1. Unblocks use of newer Logback versions. Logback 1.3.14 (December 2023) > is the last release that works with SLF4J 1.7, and several CVEs have been > fixed since then. > 2. Removes the risk of unexpected runtime breakage. SLF4J 2.0.0 is four > years old and many libraries now depend on slf4j-api 2.x. By pinning 1.7, > Flink risks runtime failures in any code that uses the fluent logging API ( > https://www.slf4j.org/manual.html#fluent). > > The change is transparent for users who don't customize logging. Users who > do will need to update dependencies manually: > 1. Projects with a direct dependency on log4j-slf4j-impl must switch to > log4j-slf4j2-impl. > 2. Projects and connectors that pin slf4j-api to 1.7 to guard against > accidentally pulling in 2.x will need to raise or drop that pin once they > build against Flink 2.4. > 3. Clusters that replace the bundled logging JARs need to drop in new > files: a newer Logback, or reload4j in place of Log4j 1.x. They already > have to track Flink's bundled versions to replace the right files. > 4. JARs in lib/ that bundle an old slf4j-api will break logging: SLF4J > finds no supported provider and falls back to NOP. > > A broken logging setup is visible on Flink's standard error. If no provider > is found, slf4j-api 2.x prints: > > SLF4J(W): No SLF4J providers were found. > SLF4J(W): Defaulting to no-operation (NOP) logger implementation > SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further > details. > SLF4J(W): Class path contains SLF4J bindings targeting slf4j-api versions > 1.7.x or earlier. > SLF4J(W): Ignoring binding found at > > [jar:file:/opt/flink/lib/log4j-slf4j-impl-2.26.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J(W): See https://www.slf4j.org/codes.html#ignoredBindings for an > explanation. > > If an old slf4j-api will be on the classpath, shadowing the bundled one, it > will print: > > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > SLF4J: Defaulting to no-operation (NOP) logger implementation > SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further > details. > SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder". > SLF4J: Defaulting to no-operation MDCAdapter implementation. > SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for > further > details. > > Do you think that the new SLF4J can land in a minor release, e.g. 2.4, or > should it wait for a future 3.0? > > Jira: https://issues.apache.org/jira/browse/FLINK-40574 > PR: https://github.com/apache/flink/pull/29120 > > -- > Thanks, > Piotr > -- Best Regards, Purushottam Sinha शुभकामनाएं पुरूषोत्तम सिन्हा
