> I think that the best course of action would be adding a separate Jetty11 module to hbase-thirdparty, this way 9.4.x and 11.0.x can be both used/updated by the 2.x / 3.x branches.
+1, I would like to volunteer for this work. Maintaining Jetty 9.4.x could be quite challenging from a CVE perspective since it has been EOCS (End of Community Support) since June 2022, and new releases may not be forthcoming for a long time. I faced similar issues during our last hbase-thirdparty release. See this issue comment: https://github.com/jetty/jetty.project/issues/12630#issuecomment-2604701092 Regarding the version and CVEs, I agree with @Andrew and suggest that we jump directly to Jetty 12, bypassing Jetty 11, to support javax.servlet for JSP 2.3.1. Therefore, I plan to use the EE8 environment on Jetty 12. See Jetty version history: https://jetty.org/download.html#version-history @Istvan, is there any particular reason you recommend moving to Jetty 11, which is also EOCS? If others are fine with me taking this up, I can create the necessary JIRAs for the Jetty migration project and start the work soon. Regards, Nihal On 2025/03/03 18:08:53 Wei-Chiu Chuang wrote: > FYI I think Hadoop will need to make similar moves too. > Sounds like Hadoop should start the work to drop JDK8 as well. I know Steve > has a patch that requires JDK17+ due to Iceberg > https://github.com/apache/hadoop/pull/7316 > > ---------- Forwarded message --------- > From: Istvan Toth <st...@apache.org> > Date: Sun, Mar 2, 2025 at 9:41 PM > Subject: [DISCUSS] Plans for JDK22 / SecurityManager removal > To: HBase Dev List <d...@hbase.apache.org> > > > Hi! > > The last big incompatible JDK change is the JEP411/JEP486 SecurityManager > removal process, which has gotten serious with JDK22, which disables > Subject.doAs*() Subject.getSubject() by default (while providing the kind > of equivalent callAs() and current() methods), and kills automatic Subject > propagation to new threads. > > To add insult to injury the new methods are only available from JDK18, so > it is not possible to just move to the new API without breaking JDK17. > > Some of this can only be solved in Hadoop (hopefully 3.5) , but HBase can > also take steps to move towards JDK22 compatibility in the meantime. > > Here's the plan I have in mind: > > - Review and the dependencies WRT SecurityManage usage (just search for API > calls) > - Update the dependencies as needed > > - Add a reflection-based compatibility Utility class based on Jetty's > SecurityUtils, (or one of its derivatives) > - Replace the deprecated method calls with the compatibility versions > - Wrap Runnables/Callables with Subject current()/callAs() methods. > > One large dependency I have identified is Jetty. > While technically we MAY be able to keep using 9.4 by overriding its > default ThreadFactory, I think that considering that even semi-formal Jetty > 9.4 support is on its very last legs (the latest update was never even > announced and is not listed in the downloads page), the advantages of > updating to Jetty 11 on branch-3+ now far outweighs the added maintenance > burden of the branch divergence. > > I think that the best course of action would be adding a separate Jetty11 > module to hbase-thirdparty, this way 9.4.x and 11.0.x can be both > used/updated by the 2.x / 3.x branches. > > What do you think ? > > - Do you agree that JEP411/486 should be treated as a priority ? > - Would you volunteer for the dependency audit ? > - Do you agree with the Jetty update, and the plan outlined above ? > > Istvan > > ps: Sorry, no links because GMail seems to react very bady to any. Please > use search. > --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
