I'd split that into two tickets. First move to Jetty 12 while keeping the old javax package names, and once that's done and tested, we can look into moving to jakarta.
Istvan On Thu, Mar 6, 2025 at 8:33 PM Andrew Purtell <apurt...@apache.org> wrote: > > Therefore, I plan to use the EE8 environment on Jetty 12. > > Ah, thanks for mentioning EE. > > Do you have a requirement to stay with EE 8 ? > > If we could target EE 9 instead of EE 8 that would align with some internal > requirements at $dayjob. For what it's worth. Mostly the point of EE 9 is a > move of the EE stuff into a new namespace, allowing for further development > under the Eclipse Foundation without trademark conflicts with Oracle's > "Java" branding. The trademark issue and follow on Java licensing concerns > are going to be relevant for anyone who might be visited by an Oracle > lawyer-shark. > > On Tue, Mar 4, 2025 at 6:42 AM Nihal Jain <nihalj...@apache.org> wrote: > > > > 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 <dev@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 > > > > > > -- > 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 > -- *István Tóth* | Sr. Staff Software Engineer *Email*: st...@cloudera.com 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> ------------------------------ ------------------------------
