-
Notifications
You must be signed in to change notification settings - Fork 1.7k
AVRO-4192: [JAVA] Update Jetty to version 12.1.4 #3542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
What is the minimum required version of Java for Jetty 12 ? Avro currently requires JDK 11+. The CI workflow is supposed to test with JDK 11, JDK 17 and JDK 21. |
| public class StaticServlet extends DefaultServlet { | ||
| private static final long serialVersionUID = 1L; | ||
|
|
||
| @Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is wrong.
The purpose of the old Default.getResource(String) is to serve the static files.
Now it seems this method is removed in Jetty 12.x and something else should be used to serve the static files. Instead of removing the @Override we need to replace this method with whatever is the new one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your comments. I will look into an alternative option/method for this in Jetty 12.x.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modified to override resolve method instead of the getResource method which was removed. Let me know if you have any further comments.
| this.plugin = plugin; | ||
|
|
||
| ServletHandler handler = new ServletHandler(); | ||
| httpServer.setHandler(handler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need similar change here as in the HttpServer:
ServletContextHandler sch = new ServletContextHandler();
sch.setServletHandler(handler);
server.setHandler(sch);There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think there is no need of ServletHandler at all.
According to one of the Jetty developers it is not really needed here - https://stackoverflow.com/a/30744577
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for your comments.
In relation to the first comment, good spot, and I think you're right. If continuing with ServletHandlers, this change should be made.
Without doing this, it may cause a "java.lang.IllegalStateException: Cannot use ServletHandler without ServletContextHandler" as was highlighted by tests for HttpServer before I made the changes in that class.
In relation to your second comment, I can look into removing/replacing the relevant ServletHandlers with ServletContextHandlers if you think that is the preferred approach here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In relation to your second comment, I can look into removing/replacing the relevant ServletHandlers with ServletContextHandlers if you think that is the preferred approach here.
+1 if it would simplify the code.
But otherwise it is not really mandatory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it ends up with fairly similar code, but I've replaced the relevant ServletHandlers with ServletContextHandlers as suggested.
According to the jetty documentation Jetty 12 needs Java 17. (ref: jetty/jetty.project#10485 | https://jetty.org/docs/jetty/12.1/index.html, etc). I did make one change relating to the java version in the top level pom file configuration under enforceBytecodeVersion maxJdkVersion to 17, as the build failed without this change (message was something like EnforceBytecodeVersion failed, found bad dependency). Perhaps this is the only place that was restricting the java version to ensure compatibility with Java 11? If avro still requires JDK 11, perhaps it is not possible to update the jetty version at this time, even though jetty 9-to-11 are all end of life now? (particularly concerning in relation to any current and future CVEs relating to no-longer-supported dependencies) |
I think it is a good idea to require JDK 17 for Avro 1.13 ( |
Signed-off-by: andrewlamb-est <andrew.a.lamb@est.tech>
33648a4 to
9dac2e0
Compare
To keep this thread updated, I created a [Discuss] thread (https://lists.apache.org/thread/fyxtndbxnxh8qcy83plzrctk88wl5srj) and a [Vote] thread (https://lists.apache.org/thread/gl0m4yx6m7w50k38fywggc862cxn330h) in the apache avro dev mailing list. Could you advise on how to properly close the vote in this mailing list? I believe it would be done with a [Result] mail, but am unsure of the numbers required for vote to pass with consensus/majority. |
|
Hello @andrewlamb-est -- just to confirm, I'm so glad that you're taking this work on. It's important! Please, it would be helpful if you would do a |
Hi @RyanSkraba, |
|
Everyone who voted is a PMC member, so there are actually 4 binding +1s. |
Sorry, I did not realize that, I would have put up a [RESULT] thread sooner. Thanks, Martin. I should have checked the PMC list (I'll make a mental note to do that in the future!) I will create a [RESULT] thread shortly. |
What is the purpose of the change
This pull request updates Jetty from 9.4.x to 12.1.4, addressing AVRO-4192.
The reason for this update is because Jetty 9, 10 and 11 have all reached End of Life.
Verifying this change
This change is already covered by existing tests, such as TestProtocolHttps and TestStatsPluginAndServlet.
Documentation