Hi all, Thanks for driving this, Piotr. I'm +1 for doing this in 2.4. There's no 3.0 planned at this moment.
I've tested the PR against its parent commit on a local cluster. The default setup keeps working. Any setup that changed the logging backend, or has a jar bundling slf4j-api 1.x ahead of flink-dist, loses all logs while jobs keep running. Besides the cases you listed, that also hits: - Job jars in lib/ for application mode, which our docs recommend, and job jars on YARN, since YARN puts user jars on the system classpath by default - The Fluss 1.0 connector, which bundles slf4j-api 1.7.36 while its docs tell users to put it in lib/ - Images that remove log4j-slf4j-impl with rm -f and then add Logback: Log4j 2 stays active and the Logback config is silently ignored - Connector tests, once they move to 2.4 with slf4j pinned to 1.7.36. DynamicKafkaSourceEnumeratorTest fails, because it asserts on log output Users on Logback 1.2 should move to 1.5, not 1.3, since 1.3.16 still has open CVEs. Piotr, can you add these cases to the docs and your release note draft? I'll add the release note to the Jira. We should also give the Fluss community a heads-up before 2.4 is released. If there are no objections by Friday 16 October, I think we can consider this agreed. Best regards, Martijn Op zo 4 okt 2026 om 18:49 schreef Piotr Przybylski <[email protected]>: > 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 > > शुभकामनाएं > > पुरूषोत्तम सिन्हा > > >
