After upgrading to 2.0.13, some issues were exposed, and we will encounter them sooner or later.
When upgrading the slf4j in the pulsar, I also encountered the problem you mentioned, so I used the `<exclusion>` to exclude the org.slf4j or org.apache.logging.log4j, and so on. Do you think this approach is fair? Thanks, Zixuan Yunze Xu <x...@apache.org> 于2024年4月26日周五 20:41写道： > Hi all, > > Recently I upgraded my downstream project's dependency to the latest > master branch and found no logs are printed now. > > ``` > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > SLF4J: Defaulting to no-operation (NOP) logger implementation > ``` > > Finally I found it's caused by #22391 [1], which upgrades the > slf4j-api version from 1.7.32 to 2.0.13. It's really a harmful change > to downstream projects. For example, assuming there is a project that > depends on the pulsar-client-all, it might adds a SLF4J binding > dependency like: > > ```xml > > <dependency> > <groupId>org.apache.pulsar</groupId> > <artifactId>pulsar-client-all</artifactId> > <version>3.2.2</version> > </dependency> > > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-simple</artifactId> > <version>1.7.36</version> > </dependency> > ``` > > Yeah it works well. However, after upgrading the pulsar-client-all to > the latest master, users have to upgrade the slf4j-simple to 2.0.13, > otherwise the logging won't work. > > Things become worse when the downstream project is large. I tried > adding the slf4j-simple or slf4j-reload4j 2.0.13 dependency to the > protocol handler project that depends on pulsar-broker and none of > them works. It has already wasted me much time debugging this logging > issue. I'm really interested in what significant change that slf4j 2.x > brings, except a higher version number that might make some developers > think it's better? > > Therefore, I suggest reverting #22391 unless there is a significant > advantage of slf4j 2.0.13. > > [1] https://github.com/apache/pulsar/pull/22391 > > Thanks, > Yunze >
