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
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
> 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
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
> 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
> 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
