Opened PHOENIX-7504 to track this. On Tue, Nov 5, 2024 at 6:18 AM Istvan Toth <st...@apache.org> wrote:
> Hi! > > The issue of slf4j 1.x vs 2.x compatibility has recently come up on > Avatica. > > While 1.x and 2.x are compatible as far as the logging API is concerned, > they are incompatible on the backend / adapter side. > > Traditionally, the (discontinued) hbase-client uberjar has shipped both > slf4j, the adapter, and the logging backend. > > With hbase-embedded-client, we've removed the adapter and the backend from > the uberjar, but we kept slf4j-api in it. > > The lesser problem is that we may effectively replace the application's > slf4-api 1.x library with ours, which may be older and buggier. > > The bigger problem is that we are locking users to slf4j1.x, as having > both slf4j 1.x and 2.x libraries on the classpath does not work reliably. > See https://www.slf4j.org/faq.html#changesInVersion200 for details. > > The solution is very simple, we simply need to provide an uberjar which > does not include slf4j-api. > > We can do it in one of two ways, neither is ideal: > > - Add a new uberjar, which is the same as an existing one (say, > hbase-client-lite), but does not include the slf4j API. The problem with > this is that even the "lite' uberjar is 140MB, and we already build three > of them, each taking ~10 minutes to build, so this would bloat our > assembly, and build times. > > - Change one of the existing uberjars, preferably phoenix-client-lite, and > remove slf4j-api from it. > This would be an incompatible change, but we avoid bloating the assembly > and the build time. > I feel that phoenix-client-lite is new enough (and few enough people > know that it even exists) that this probably won't break a lot of existing > use cases, (also the fix is as easy as adding slfj4-api to the classpath). > > I'm leaning towards the second option. > > WDYT ? > >
