I submitted a PR to fix this issue:
https://github.com/apache/pulsar/pull/22607
Yunze Xu 于2024年4月27日周六 14:27写道：
> > 1.7 has not been maintained for almost 2 years.
>
> Logging is only a very simple part. SLF4J is even just a logging
> facade that has less chance to suffer CVEs like log4j2. Unles
> 1.7 has not been maintained for almost 2 years.
Logging is only a very simple part. SLF4J is even just a logging
facade that has less chance to suffer CVEs like log4j2. Unless there
is any CVE found for slf4j, breaking the user case is worse than
upgrading the slf4j.
> when the slf4j version is
> I don't think so. As a logging facade, there is no convincing reason
> to keep it latest unless some CVEs.
I think it's better to keep up with the latest version, as we always get
support from the community. 1.7 has not been maintained for almost 2 years.
>The point is not related to how I shou
The point is not related to how I should resolve the dependency issue.
It is how you care for the downstream users.
Assuming there is an application that depends on pulsar-client 3.0.0
running well. Then after some days, maintainers tried upgrading the
pulsar-client to 3.3.0 and they found logs do
> 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 `` to exclude the org.slf4j or
> org.apache.logging.log4j, and so on.
As I've mentioned before, things become complicated once your
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 `` to exclude the org.slf4j
or org.apache.logging.log4j, and so on.
Do you think this approach is fa
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 #223
