Hi, It's been some time since I began this thread, so I'm sending a reminder in case more people would like to voice their opinion.
-- Thanks, Piotr czw., 24 wrz 2026 o 15:02 P Sinha <[email protected]> napisał(a): > +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 > शुभकामनाएं > पुरूषोत्तम सिन्हा >
