Another issue that came to my mind is the phoenix-client jar. We're currently shading log4j1 (actually reload4j) into the JAR.
Our options are (in the order of my preference): * drop phoenix-client (and make users migrate to phoenix-client-embedded) * switch phoenix-client to log4j2 * we could also keep shading reload4j into it, but that would defeat the purpose of switching backends. If we change the logging backend in phoenix-client, we're already changing the dependent application's logging environment, so users may as well switch to phoenix-client-embedded, and take control of their backend. Istvan On Mon, Apr 25, 2022 at 6:47 PM Istvan Toth <st...@cloudera.com> wrote: > Thanks, Geoffrey. > > I actually plan to push the logger changes in a separate JIRA/Commit. > Seems like the Hbase 2.5 artifacts don't actually depend on any logging > backend (which is nice), > so the current log4j1 backend works fine with minimal (test only) pom > changes. > > > > On Mon, Apr 25, 2022 at 5:50 PM Geoffrey Jacoby <gjac...@apache.org> > wrote: > >> It's a tough question because my instinct is to run whatever logging >> system >> HBase uses, and that's reload4j in 2.4 and log4j2 in HBase 2.5. >> >> But trying to have it both ways with complicated profile magic seems like >> it would add a lot of complexity, likely more than it's worth. >> >> Since log4j2 is the "future-proof" option that HBase is going to support >> not just in 2.5 but in any future 2.6 or 3.0 going forward, I'm +1 for >> moving to log4j2 as part of adding HBase 2.5 support. >> >> Geoffrey >> >> On Mon, Apr 25, 2022 at 4:14 AM Istvan Toth <st...@apache.org> wrote: >> >> > Hi! >> > >> > We've had a discussion >> > <https://lists.apache.org/list?dev@phoenix.apache.org:2022-1:[DISCUSS]> >> on >> > the replacement of log4j a few months ago. >> > There were not a lot of replies, but based on Andrew's suggestion we've >> > switched Phoenix over to reload4j as a short-term fix (as that doesn't >> > require any changes by users). >> > >> > However, we want to support the upcoming HBase 2.5 in Phoenix 5.2 >> > (PHOENIX-6692), and the log4j changes have recently been backported to >> > branch-2.5, meaning that HBase 2.5 no longer uses log4j1 at all. >> > >> > This adds some urgency to choosing a "final" solution in Phoenix. >> > >> > Being built on top of HBase, I propose that we simply follow HBase's >> lead, >> > and go with log4j2, as not having to work with two logging backends is >> the >> > easiest both for us as developers and for our users. >> > >> > Looking at the HBase changes, Hbase pulls in >> > org.apache.logging.log4j:log4j-1.2-api , which means log4j2 can also >> handle >> > any log4j using components (hadoop, zookeeper), and a single log4j2 >> config >> > file should be enough for the whole stack. >> > >> > The changes would look like something like this: >> > >> > - Explicitly exclude the log4j (and sl4j-logj12) libraries from all >> > dependencies >> > - Explicitily add the same log4j2 dependencies as HBase to phoenix-core >> > (and remove reload4j) >> > - Replace the log4j config file in the assembly and tests with a log4j2 >> > config file >> > - Modify the startup scripts. >> > - Add the logging libraries to the assemblies (and remove reload4j) >> > >> > This needs to be done in Omid, the queryserver, and perhaps in the >> > connector repos as well. >> > >> > WDYT ? >> > >> > Istvan >> > >> > > > -- > *István Tóth* | Staff Software Engineer > st...@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> > <https://www.cloudera.com/> > ------------------------------ >
