Hi Colin and Chia, thank you for your feedback. Currently we have only reload4j binding dependency, and we can continue with the same. I have updated kip with only reload4j, and removed all other providers. And if users have a different slf4j provider, they can continue to keep it in the classpath.
With this, I think, users don't have to make any explicit changes in their code, if their provider is reload4j. And if it's a different provider (like logback, log4j), they would have to upgrade that to match it with slf4j. And we may not have to file a new kip, for every slf4j upgrade, if we agree with the same approach ? Thanks, Murali On Sun, Sep 15, 2024 at 8:50 AM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > > Colin McCabe <cmcc...@apache.org> 於 2024年9月15日 凌晨4:26 寫道： > > I'm also not totally convinced that we need to provide so many logging > systems. It feels odd to bring in so many dependencies without having a > clear idea of who is using them. We didn't do this earlier and nobody > complained. Putting more stuff on the CLASSPATH can lead to problems for > people. > > If we all agree “no nobody will complain the possible compatibility issue > when we upgrade the slf4j api in the future”, it is fine to NOT add all > providers to classpath. > > I was +1 to ignore the possible compatibility issue before, but user need > to add extra (slf4j provider) jar to classpath if they want to run with > different slf4j provider. It seems that is a kind of API requisite so we > need to be careful about the compatibility issue. However, it is a bit > weird to file KIP to update slf4j api every time… > > Best, > Chia-Ping > > > > >
