It shouldn't be necessary to shade the logger, if you are using SLF4J everywhere as logging facade in Phoenix, as I believe you are. Exclude log4j and reload4j for shading into the client jar, and supply them in lib/ instead in your convenience artifact. The user can opt to include them on the classpath or provide their own solution. They are required to have some SLF4J implementation jar on the classpath already by HBase etc, but it can be whatever they decide.
On Mon, Apr 25, 2022 at 10:33 PM Istvan Toth <st...@apache.org> wrote: > 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/> > > ------------------------------ > > > -- Best regards, Andrew Unrest, ignorance distilled, nihilistic imbeciles - It's what we’ve earned Welcome, apocalypse, what’s taken you so long? Bring us the fitting end that we’ve been counting on - A23, Welcome, Apocalypse
