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