There is no agreement on the upgrade. I have closed the ticket, and opened *HBASE-29832 Make it easy to use HBase with SLF4j 2.x* as a follow-up ticket.
On Thu, Dec 11, 2025 at 3:59 PM Istvan Toth <[email protected]> wrote: > Yes, the SLF4J 1.7.x API is a subset of the SLF4j 2.x API. > > If a downstream app (i.e. one that uses hbase-client) is using currently > using slf4j2, > and they are using maven-like dependency management , then yes, they need > to > exclude any slfj4 1.x dependencies coming from HBase which are not > overridden > by their own explicit slf4j dependency versions. > > If we update HBase to use slf4j2, then the same will have to be done for > applications still using > slf4j1.x. > > You are right that currently we don't gain new functionality by upgrading > because we need to avoid the > new APIs. two plusses: > > - We'll be on an actively developed and supported branch, which makes > users and static checkers happier > - At some point slfj4 2 will become dominant, and a new major version is > the best point to make such a change. > > If we don't upgrade now, then 4.0 is going to be the next natural point. > > > > On Thu, Dec 11, 2025 at 2:49 PM 张铎(Duo Zhang) <[email protected]> > wrote: > >> Then if we can not use any new features in slf4j2, which is the >> advantage to upgrading to slf4j2? >> >> And as long as slf4j1 and slf4j2 can not live together, what is the >> suggested way for our users? Exclude slf4j1 and add slf4j2 >> dependencies manually? As Slf4j2 is compatible with slf4j1 but not >> vice versa? >> >> Thanks. >> >> Istvan Toth <[email protected]> 于2025年12月11日周四 21:39写道： >> > >> > slf4j 2 is backwards API compatible with slf4j 1. >> > (Confirmed by HBase compiling fine after changing the version.) >> > >> > slf4j 1 and 2 don't work together, you need to include one of the 1.7.x >> or >> > 2.x slfj4-api jars, >> > and you need to match the other slf4j jars' versions to the API. >> > >> > Changing HBase to use slf4j2 is not expected to affect applications >> using >> > slf4j1. >> > As long as we don't use the slf4j specific features from slf4j-api 2.x, >> > like the >> > fluent API, HBase will continue working with the slf4j 1.x API and other >> > jars. >> > >> > The only problem I can see is if the application is adding slf4j 1.x >> jars >> > statically, >> > or via maven etc, and the slf4j 2 jars are also somehow added to the >> > classpath >> > without overriding the slf4j 1.x versions. >> > >> > Having both slf4j 1 and 2 jars mixed on the classpath is asking for >> > trouble, unless you can >> > control their ordering. >> > >> > I can see some logging specific test failures in my slf4j2 PR, I'm gonna >> > look into them. >> > >> > Istvan >> > >> > On Thu, Dec 11, 2025 at 1:35 PM 张铎(Duo Zhang) <[email protected]> >> wrote: >> > >> > > In general, a HBase cluster instance is bound with log4j2, if users >> > > want to use other logging frameworks they need to do some magic, like >> > > replacing the logging jars and writing configuration files on their >> > > own. >> > > >> > > But another usage is that, users may depend on hbase-client, >> > > hbase-testing-util in their own java problem, where we only depend on >> > > slf4j so users are free to use their own logging frameworks. >> > > >> > > For the first usage, it is free for us to change the logging facade, >> > > we only need to consider the second usage. We need to figure out a way >> > > that how slf4j1 and slf4j2 can work together without problems, as >> > > users may depend on different jars and some of them may depend on >> > > slf4j1 and some of them may depend on slf4j2(I guess there is way as >> > > there are already bunch of jars which depend on slf4j2). >> > > >> > > Thanks. >> > > >> > > Istvan Toth <[email protected]> 于2025年12月11日周四 18:38写道： >> > > > >> > > > Luckily HBase is basically doing the right thing already, and none >> of our >> > > > uberjars have any logging (slf4j or backend) classes, neither >> relocated >> > > nor >> > > > unrelocated. >> > > > >> > > > I cannot think of a use case where we would want to shade in logging >> > > > classes. >> > > > >> > > > IIRC shading the slf4j and logging backend jars was problematic with >> > > SLF4j >> > > > 1.x as well. >> > > > >> > > > Technically, I think that the services mechanism would work when >> shaded, >> > > as >> > > > long as >> > > > we shade everything (slf4j, provider, logging backend) in. >> > > > If only some classes are shaded in, then they probably won't >> > > > work. (But I don't think we should do that at all) >> > > > >> > > > We want consumers of the HBase client to be able to bring their own >> > > logging >> > > > backend >> > > > and slf4j provider classes so that HBase uses the same logging >> infra as >> > > the >> > > > application. >> > > > >> > > > We do provide our defaults in the "hbase classpath" list but the >> user can >> > > > replace those. >> > > > >> > > > The mapreduce classpath is always a problem as Hadoop only >> partially uses >> > > > slf4j, so we >> > > > include our logging classes in the "hbase mapredcp" list, and try >> to make >> > > > sure that those >> > > > come before Hadoop's logging classes on the classpath. >> > > > >> > > > In fact, as long as only HBase is using log4j2, it will reduce >> logging >> > > > confusion, as >> > > > log4j2-api won't pick up the log4j1 adapter classes coming from >> Hadoop or >> > > > elsewhere. >> > > > >> > > > I'm going to run some tests with slf4j2 and the byo-hadoop HBase >> > > > distribution, and report here. >> > > > >> > > > Thanks, >> > > > Istvan >> > > > >> > > > On Thu, Dec 11, 2025 at 10:44 AM Nick Dimiduk <[email protected]> >> > > wrote: >> > > > >> > > > > I think the discuss thread is wise here. The logging API is >> > > > > effectively part of our public API (in terms of our compatibility >> > > > > guarantees), so it's worth noting. >> > > > > >> > > > > With the service selection mechanism, will this introduce any >> troubles >> > > for >> > > > > us if we're shading the implementation jar? Maybe there's no >> reason >> > > that we >> > > > > would want to... >> > > > > >> > > > > Nice one Istvan. >> > > > > >> > > > > Thanks, >> > > > > Nick >> > > > > >> > > > > On Thu, Dec 11, 2025 at 10:08 AM Istvan Toth <[email protected]> >> wrote: >> > > > > >> > > > > > Hi! >> > > > > > >> > > > > > I think that it's time to upgrade to slf4j 2.x in HBase. (3.0+, >> but >> > > > > > possibly 2.7 as well) >> > > > > > SLF4j 1 is no longer developed, and SLF4j 2 has some nice new >> > > features >> > > > > like >> > > > > > the fluent API which makes logging more efficient. >> > > > > > >> > > > > > The only major change that I think may affect us is that the >> logging >> > > > > > backend is now selected via the services mechanism, instead of >> > > searching >> > > > > > the classpath for implementations, and is explicitly >> configurable. >> > > > > > >> > > > > > I was hesitant to open this thread as the code change is >> trivial, but >> > > > > log4j >> > > > > > is such a fundamental library that I decided to go for a wider >> > > > > discussion. >> > > > > > >> > > > > > https://issues.apache.org/jira/browse/HBASE-29769 >> > > > > > >> > > > > > best regards >> > > > > > Istvan >> > > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > *István Tóth* | Sr. Staff Software Engineer >> > > > *Email*: [email protected] >> > > > cloudera.com <https://www.cloudera.com> >> > > > [image: Cloudera] <https://www.cloudera.com/> >> > > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >> > > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> > > Cloudera >> > > > on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > > > ------------------------------ >> > > > ------------------------------ >> > > >> > >> > >> > -- >> > *István Tóth* | Sr. Staff Software Engineer >> > *Email*: [email protected] >> > cloudera.com <https://www.cloudera.com> >> > [image: Cloudera] <https://www.cloudera.com/> >> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >> > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> Cloudera >> > on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > ------------------------------ >> > ------------------------------ >> > > > -- > *István Tóth* | Sr. Staff Software Engineer > *Email*: [email protected] > cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> > ------------------------------ > ------------------------------ > -- *István Tóth* | Sr. Staff Software Engineer *Email*: [email protected] cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------ ------------------------------
