> 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. Sticking to 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 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 suggest we use the EE8 environment on Jetty 12. See 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 Tue, 4 Mar 2025 at 2:27 AM, Istvan Toth <st...@apache.org> wrote: > Thanks for your reply, Andrew. > > If no-one else picks it up, I will try to start working on moving to Jetty > 12 in a few weeks. > > On the importance of recent Java support: (which doesn't change the fact > that we're at the mercy of Hadoop releases) > > I also used to think that it's not important to support the latest Java > versions, but recent discussions with the Trino team have changed my mind. > My new understanding is that there are an increasing number of users and > projects who are aggressively moving to the latest Java versions, both > applications and libraries (for example Trino), > and if we don't keep up, then HBase/Phoenix becomes a non-starter by simply > not running in their JVMs. > > Yes, probably 80% of the current users and 90+% percent of nodes are > enterprises and other very risk-averse entities that wouldn't even > consider a non-LTS java version, but by lagging with Java support, we are > driving off new adapters that are vital for the long-term health of the > project. > > By keeping up with non-LTS versions, we also get a head-start, and are much > more likely to support new LTS releases on day one. > > Istvan > > On Mon, Mar 3, 2025 at 6:07 PM Andrew Purtell <apurt...@apache.org> wrote: > > > I don't think compatibility with the very most recent Java version is a > > primary requirement for this project. Identifying the issues and > proposing > > a plan as has been done here is great. Beyond that, if someone has the > > burning need to move to Java 22 or later we should here about it then by > > user filed JIRAs or PRs or mailing list posts asking about breaks caused > by > > SecurityManager removal. Should Hadoop take steps we could also leverage > > that, after the change lands in a released version we can consume. > > > > The dependency on the old version of Jetty that seems about to fall out > of > > maintenance seems like a more immediate issue, given that Jetty is a > > frequent flyer for security issues and has a number of (solved) CVEs > posted > > over the past few years. > > > > > I think that the best course of action would be adding a separate Jetty > > 12 > > > 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 > > Presumably JIRAs/PRs to move up to Jetty 12 would follow. I think we can > > find helpers for a Jetty 12 uplift at the $dayjob here also. > > > > > > On Mon, Mar 3, 2025 at 5:50 AM Istvan Toth <st...@apache.org> wrote: > > > >> Correction: I meant Jetty 12 > >> > >> On Mon, Mar 3, 2025 at 6:41 AM Istvan Toth <st...@apache.org> wrote: > >> > >> > 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. > >> > > >> > > >> > > > > > > -- > > 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 > > >
