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