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
