> we will encounter them sooner or later.
I don't think so. As a logging facade, there is no convincing reason
to keep it latest unless some CVEs.
> so I used the `<exclusion>` to exclude the org.slf4j or
> org.apache.logging.log4j, and so on.
As I've mentioned before, things become complicated once your project
is large. For example, the KSN project relies on the SLF4J from Pulsar
implicitly because it expects the Pulsar dependency carries the SLF4J
dependency.
```
<artifactId>pulsar-broker</artifactId>
<artifactId>pulsar-broker-auth-sasl</artifactId>
<artifactId>pulsar-client-original</artifactId>
<artifactId>pulsar-client-auth-sasl</artifactId>
<artifactId>pulsar-common</artifactId>
<artifactId>pulsar-client-admin-original</artifactId>
```
I have to exclude the slf4j dependency for each `pulsar-*` dependency.
Then import both the `slf4j-api` and `slf4j-log4j12` dependencies in
the root pom.xml.
```
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>${slf4j.version}</version>
<scope>runtime</scope>
</dependency>
</dependencies>
```
And then it works, but it also shows how much changes are needed
caused by such a PR in the upstream. Existing users might already
depend on the carried slf4j dependency from Pulsar. The point is the
upgrade could BREAK many existing downstream projects.
Thanks,
Yunze
On Sat, Apr 27, 2024 at 1:21 AM Zixuan Liu <node...@gmail.com> wrote:
>
> 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
> >
