Apologies for the formatting glitch in the previous email. It seems some mail clients automatically collapsed the section for Option 2. Please be sure to click on it to expand the details.
On 2025/09/01 14:37:47 Nihal Jain wrote: > Hi team, > > I'm initiating this discussion regarding the most effective approach for > HBASE-29542: migrating to Jetty 12 with the Jakarta EE10 namespace (Phase > 2). We've already completed Phase 1 of this migration (i.e. Jetty 9 to > Jetty 12 with EE8) under HBASE-29224. > > Our primary challenge forthis next phase is our reliance on Hadoop's > AuthenticationFilter, which is built with the javax.servlet namespace. To > bridge this compatibility gap, I've identified three main options and > created corresponding JIRA tickets: > > Option 1: Decouple via Source Fork (HBASE-29557) > This involves creating a new hbase-auth-filters module and directly copying > the necessary Hadoop authentication source code. > > JIRA: https://issues.apache.org/jira/browse/HBASE-29557 > > <https://issues.apache.org/jira/browse/HBASE-29557>Pros: > * Complete decoupling from Hadoop's release timeline, allowing immediate > progress with full control. > * The underlying filter code is relatively stable and historically has not > required frequent changes, which may lower the maintenance risk. > * Eventually, we could refactor and move all existing filter-related code > within HBase to this new module, improving modularity. > > Cons: We would still assume the maintenance burden of a source fork, > including monitoring and backporting any security fixes from upstream > Hadoop. > > --- > > Option 2: Shade and Transform (HBASE-29563) > This approach will use the Maven Shade Plugin to create a private, > transformed copy of required Hadoop classes during the build process. This > includes isolating, relocating classes to an org.apache.hbase.shaded > namespace, and transforming their bytecode from javax to jakarta. > > JIRA: https://issues.apache.org/jira/browse/HBASE-29563 > > Pros: > * Avoids a source fork, simplifying maintenance. > * Upstream fixes can be easily incorporated by updating the Hadoop > dependency, and relocation prevents classpath conflicts. > > Cons: > * Introduces some complexity to our build configuration, though this is a > well-established pattern. > * Upstream API changes in the Hadoop library could cause build or runtime > failures. > > --- > > Option 3: Wait for Hadoop (HADOOP-19395) > > This option entails pausing our migration efforts until the Hadoop > community completes their migration to the jakarta namespace. > > JIRA: https://issues.apache.org/jira/browse/HADOOP-19395 > > Pros: Requires no immediate work from our end. > > Cons: > * Leaves us indefinitely blocked by another project's schedule and > priorities. > * Once Hadoop migrates, we would likely face the added complexity of > supporting both pre- and post-Jakarta versions of Hadoop. > > --- > > I would like to gather the team's perspective on these options to determine > the best path forward. Please go over the JIRAs for more details and share > your thoughts. > > Thanks, > Nihal >
