I created a pull request for removing jul-to-slf4j[1] and it seems all
existing tests aren't affected.
The Pulsar project uses slf4j as the logging facade consistently. If a user
want to add a dependency using a different logging framework, they should
take care of the packaging strategy themselve
cc users@,
Here is a discussion to remove jul-to-slf4j from pulsar's dependency tree.
I'd like to do an investigation that whether any user depends on this
transitive dependency for:
1. Implicitly add jul-to-slf4j to classpath from a pulsar-xxx fatjar.
2. Implicitly calling:
SLF4JBridgeHandler
Thanks for your input @Enrico! I'll do some investigation in these two
weeks.
Does this estimate meet the schedule of 2.11?
BTW, there is another dependency change PR[1] waiting for review. I don't
want
to mix this thread but throw it here under the same topic for more
visibility.
Best,
tison.
[
Tison,
Il giorno mar 21 giu 2022 alle ore 12:44 tison
ha scritto:
>
> Hi devs,
>
> I learn that PulsarAdminImpl has a static block requires classpath contains
> exact either of
>
> * slf4j-jdk14
> * jul-to-slf4j
>
> I'm curious what logging framework Pulsar choose among the codebase.
AKAIF we ar
Hi devs,
I learn that PulsarAdminImpl has a static block requires classpath contains
exact either of
* slf4j-jdk14
* jul-to-slf4j
I'm curious what logging framework Pulsar choose among the codebase.
Basically we should
depend on either jul facade or slf4j facade, and leave the class loading
issu
