Hi Istvan, Do you expect any problems for coprocessors and Phoenix?
-- Tamaas On Thu, Dec 11, 2025 at 2:39 PM Istvan Toth <[email protected]> wrote: > 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> > ------------------------------ > ------------------------------ >
