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