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. [1] https://github.com/apache/pulsar/pull/16109 Enrico Olivelli <eolive...@gmail.com> 于2022年6月21日周二 19:15写道： > Tison, > > Il giorno mar 21 giu 2022 alle ore 12:44 tison <wander4...@gmail.com> > 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 are using only SLF4J in Pulsar codebase. > maybe jul-to-slf4j is there only for historical reasons > > ideally jul-to-slf4j is only something you should care about only > during packaging, for runtime (or you can add it also for with test > scope) > > we could try to remove it for the next major release (2.11) > > Would you like to do some trials ? > > Enrico > > > > Basically we should > > depend on either jul facade or slf4j facade, and leave the class loading > > issue to users who > > include libraries depending on other logging framework. > > > > Current logic causes an issue that if user doesn't depend on both > > slf4j-jdk14 and jul-to-slf4j, > > PulsarAdminImpl will panic because it requires exact one of these two > deps > > in the classpath. > > And thus user should add one of them (basically jul-to-slf4j) even if > they > > don't depend on it > > effectively. > > > > Best, > > tison. >
