Repository navigation
HADOOP-19970. Move the servlet API to javax.servlet-api 4.0.1. - #8699
Draft
joseluisll wants to merge 7 commits into
Draft
joseluisll wants to merge 7 commits into
joseluisll wants to merge 7 commits into
Conversation
joseluisll
force-pushed
the
jetty-phase-a
branch
from
August 21, 2026 18:10
9aa1997 to
ce75ddb
Compare
|
💔 -1 overall
This message was automatically generated. |
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Aug 23, 2026
ShuffleChannelHandler is a Netty handler. It imported org.eclipse.jetty.http. HttpHeader only to name the Connection and Keep-Alive headers, and the same file already imports Netty's HttpHeaderNames.CONTENT_TYPE. Use HttpHeaderNames and HttpHeaderValues throughout. That was the module's only Jetty reference in main sources, so the module no longer uses Jetty at all outside tests. Netty's constants are lowercase AsciiStrings, so the response now carries "connection: keep-alive" where it carried "Connection: Keep-Alive". Field names are case-insensitive per RFC 7230 section 3.2, connection options are case-insensitive per section 6.1, and the response already carried Netty's lowercase "content-length" from HttpUtil.setContentLength, so this makes the response more internally consistent rather than less. No shuffle client reads these headers by name; the fetcher uses HttpURLConnection, which is case-insensitive. Note for HADOOP-19970 (apache#8699): that PR adds a jetty-http dependency to this module's pom for exactly this import. With the import gone the declaration is no longer needed and should be dropped from that PR. Contains content generated by Claude. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Aug 23, 2026
ShuffleChannelHandler is a Netty handler. It imported org.eclipse.jetty.http. HttpHeader only to name the Connection and Keep-Alive headers, and the same file already imports Netty's HttpHeaderNames.CONTENT_TYPE. Use HttpHeaderNames and HttpHeaderValues throughout. That was the module's only Jetty reference in main sources, so the module no longer uses Jetty at all outside tests. Netty's constants are lowercase AsciiStrings, so the response now carries "connection: keep-alive" where it carried "Connection: Keep-Alive". Field names are case-insensitive per RFC 7230 section 3.2, connection options are case-insensitive per section 6.1, and the response already carried Netty's lowercase "content-length" from HttpUtil.setContentLength, so this makes the response more internally consistent rather than less. No shuffle client reads these headers by name; the fetcher uses HttpURLConnection, which is case-insensitive. Note for HADOOP-19970 (apache#8699): that PR adds a jetty-http dependency to this module's pom for exactly this import. With the import gone the declaration is no longer needed and should be dropped from that PR. Contains content generated by Claude. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
slfan1989
self-requested a review
August 24, 2026 01:27
pan3793
reviewed
Aug 24, 2026
Member
This is the beginning of chaos. And in practice, during the migration, it's likely that we need both |
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Aug 24, 2026
ShuffleChannelHandler is a Netty handler. It imported org.eclipse.jetty.http. HttpHeader only to name the Connection and Keep-Alive headers. That was the module's only Jetty reference in main sources, so with it gone the module does not use Jetty at all, tests included. The names are spelled out as constants rather than taken from Netty's HttpHeaderNames and HttpHeaderValues, whose constants are lowercase AsciiStrings: using those would have sent "connection: keep-alive" where this handler has always sent "Connection: Keep-Alive". Field names and connection options are both case-insensitive per RFC 7230, and Hadoop's own fetcher uses HttpURLConnection, but the shuffle response is read by other projects too and there is no reason to change a byte of it here. Note for HADOOP-19970 (apache#8699): that PR adds a jetty-http dependency to this module's pom for exactly this import. With the import gone the declaration is no longer needed and should be dropped from that PR. Contains content generated by Claude. Co-Authored-By: Claude <noreply@anthropic.com>
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Aug 24, 2026
ShuffleChannelHandler is a Netty handler. It imported org.eclipse.jetty.http. HttpHeader only to name the Connection and Keep-Alive headers. That was the module's only Jetty reference in main sources, so with it gone the module does not use Jetty at all, tests included. The names are spelled out as constants rather than taken from Netty's HttpHeaderNames and HttpHeaderValues, whose constants are lowercase AsciiStrings: using those would have sent "connection: keep-alive" where this handler has always sent "Connection: Keep-Alive". Field names and connection options are both case-insensitive per RFC 7230, and Hadoop's own fetcher uses HttpURLConnection, but the shuffle response is read by other projects too and there is no reason to change a byte of it here. Note for HADOOP-19970 (apache#8699): that PR adds a jetty-http dependency to this module's pom for exactly this import. With the import gone the declaration is no longer needed and should be dropped from that PR. Contains content generated by Claude. Co-Authored-By: Claude <noreply@anthropic.com>
joseluisll
force-pushed
the
jetty-phase-a
branch
from
August 24, 2026 20:16
cff271a to
0427e2a
Compare
joseluisll
changed the title
joseluisll
changed the title
Member
The jakarta.servlet groupId does not imply the jakarta.servlet package. Version 4.0.x was just the artifact rename under the Eclipse Foundation — the classes are still javax.servlet.http.HttpServlet. The actual package rename ("big bang") landed in 5.0.0. So if you see jakarta.servlet-api:4.0.4 on a classpath, your imports are still javax.*. |
Contributor
Author
|
With the three substasks HADOOP-19970, HADOOP-19971 and HADOOP-19972, we have migrated to jetty12-ee8 as an intermediate step, not breaking downstream consumers. I'm still testing the pr's results, it would be convenient to create a specific subtask for compatibility testing before releasing the intermediate step. Any idea on how to approach the compatibility testing is welcome. The breaking changes should be delivered in a future and additional release, giving time anf instructions for consumers to adapt to the namespace change, that is, using the jakarta instead of the javax classes. This changes also introduce jdk-17 as a requirement, they are no longer jdk-8 compatible due to jetty12. |
Member
@pjfanning that's true. so in the process of namespace migration, we might mix in
but this might not be a real issue for hadoop project, since it stays near the root of the big data ecosystem dependency tree |
pan3793
reviewed
Aug 26, 2026
pan3793
reviewed
Aug 26, 2026
|
💔 -1 overall
This message was automatically generated. |
joseluisll
force-pushed
the
jetty-phase-a
branch
from
August 31, 2026 11:11
077558a to
236e4bd
Compare
joseluisll
force-pushed
the
jetty-phase-a
branch
2 times, most recently
from
September 4, 2026 04:38
45defb4 to
cfb6dbb
Compare
4 of 6 tasks
Contributor
|
ℹ️ Cloud-AWS manual trigger instructions: S3A tests must be manually triggered for fork pull requests. A maintainer should:
fork head: |
joseluisll
force-pushed
the
jetty-phase-a
branch
from
November 1, 2026 21:04
33792da to
a8228ea
Compare
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 1, 2026
…he catalog-webapp and timelineservice-hbase tests.
catalog-webapp: on solr-core and solr-test-framework, exclude Solr's own
Jetty modules (jetty-alpn-server, jetty-alpn-java-server,
jetty-continuation, jetty-deploy, jetty-jmx, jetty-rewrite,
jetty-security, jetty-servlets, http2-server) and javax.servlet-api.
The tests reach Solr only through EmbeddedSolrServer, so only
${jetty.version} stays on the test classpath.
timelineservice-hbase-tests: on hbase-server and hbase-server:tests,
exclude javax.servlet:javax.servlet-api, as hbase-server-2 already does.
Also exclude jetty-alpn-java-client from solr-core and solr-test-framework.
Both Solr artifacts declare jetty-alpn-java-client 9.4.44. The managed
9.4.58 copy won only through Maven's declaration-order tie-break via
http2-http-client-transport. Exclude it, as solr-solrj already does.
Declare the Solr exclusions once, in catalog-webapp's dependencyManagement.
solr-core and solr-test-framework carried the same 22 exclusions, so a Solr
upgrade that adds a Jetty artifact had to be fixed in both places, and
missing one would bring back a second Jetty release (review on PR apache#8699).
They now live once, in a dependencyManagement section local to
hadoop-yarn-applications-catalog-webapp, with the Solr version; the two
test-scope dependencies only name the artifacts.
Local rather than in hadoop-project: only this module uses Solr, and it
keeps the change out of the root pom.
No change in what the module resolves: dependency:list (test scope) gives
the same 238 artifacts before and after, all Jetty at ${jetty.version} and
no javax.servlet-api 3.1.0.
Keep a single Solr exclusion list, on solr-test-framework.
The previous change moved both Solr artifacts into a local
dependencyManagement, but solr-core and solr-test-framework still each
carried the same 22 exclusions, so the list was not declared once.
The tests use solr-core only through EmbeddedSolrServer and NodeConfig,
and solr-test-framework already depends on solr-core. Drop the direct
solr-core declaration and the local dependencyManagement, and declare
solr-test-framework (test scope) once, with the only exclusion list.
The resolved test classpath of catalog-webapp is unchanged: the same
238 artifacts, solr-core 8.11.2 still at test scope, and no
javax.servlet-api 3.1.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 1, 2026
javax.servlet:javax.servlet-api 3.1.0 and jakarta.servlet:jakarta.servlet-api 4.0.4 both publish the javax.servlet packages, and which one a module compiles and runs against depends on jar order. Leave one servlet API jar: org.eclipse.jetty.toolchain:jetty-servlet-api, the one Jetty 12's ee8 environment depends on. * hadoop-project: add jetty-servlet-api.version (4.0.9) and manage org.eclipse.jetty.toolchain:jetty-servlet-api in place of jakarta.servlet:jakarta.servlet-api 4.0.4. * hadoop-common: declare jetty-servlet-api at compile scope. HttpServer2 and its filters compile against javax.servlet, which today arrives only as javax.servlet-api 3.1.0 through jetty-server; the modules that use javax.servlet without declaring an API get it through hadoop-common. * hadoop-project and hadoop-sls: the exclusion on jetty-server named org.eclipse.jetty:javax.servlet-api, a coordinate that matches nothing. It now names javax.servlet:javax.servlet-api. * hadoop-project: on javax-websocket-server-impl, also exclude javax.servlet:javax.servlet-api (through websocket-servlet). * The 17 module poms that declare the servlet API, and the 5 exclusions of it (4 in hadoop-client-minicluster, 1 in hadoop-yarn-common), move to the new coordinate. * hadoop-project: jersey-test-framework-core declares jakarta.servlet-api at compile scope; exclude it there and on the Jersey test provider. * LICENSE-binary: replace jakarta.servlet:jakarta.servlet-api:4.0.4 with org.eclipse.jetty.toolchain:jetty-servlet-api:4.0.9 (Apache License 2.0 / EPL 2.0, like the other Jetty artifacts). * LICENSE-binary and NOTICE-binary: drop javax.servlet:javax.servlet-api. No Jetty version change. jetty-servlet-api and jakarta.servlet-api 4.0.4 ship the same javax.servlet 4.0 classes, a superset of 3.1, and Jetty 9.4 runs on Servlet 4.0. Downstream: non-shaded artifacts now bring the servlet API as org.eclipse.jetty.toolchain:jetty-servlet-api instead of jakarta.servlet:jakarta.servlet-api, so exclusions of the old coordinate need the new one; direct consumers of hadoop-common get jetty-servlet-api 4.0.9 instead of javax.servlet-api 3.1.0. hadoop-client-runtime still relocates one servlet API, now taken from jetty-servlet-api. Add classpath tests for one servlet API and one Jetty release. hadoop-common, the shuffle handler, yarn-common, the ApplicationHistoryServer, the NodeManager and the Router each get a TestJettyClasspath that checks their test classpath: javax/servlet/Servlet.class comes from exactly one jar, jetty-servlet-api, and every Jetty jar is from the same release. Following the review on PR apache#8699: * The tests live once, in AbstractJettyClasspathTest in hadoop-common's test jar, which every one of these modules already depends on. Each module's TestJettyClasspath is an empty subclass; JUnit 5 runs the inherited tests, so the modules cannot drift apart. * ClasspathTestUtils recognises Jetty jars by the Maven repository layout, .../org/eclipse/jetty/[group/...]artifact/version/artifact-version.jar, in any Jetty group, so stale http2, fcgi or websocket jars beside ${jetty.version} fail the test. The groups whose artifacts are versioned on their own (toolchain, alpn, orbit) are left out. With trunk's poms, testSingleServletApi fails in hadoop-common: javax.servlet-api 3.1.0 provides javax/servlet/Servlet.class. Exclude the jakarta.servlet-api of the Jersey test framework only once. jersey-test-framework-core brings the servlet API as jakarta.servlet:jakarta.servlet-api, and the managed jersey-test-framework-core in hadoop-project already excludes it. Managed exclusions also apply where core arrives transitively and where it is declared with exclusions of its own, so the other declarations were redundant or dead (review on PR apache#8699): - hadoop-project: drop the jakarta.servlet-api exclusion repeated on the managed jersey-test-framework-provider-jetty. - hadoop-yarn-common and hadoop-client-minicluster: drop the exclusions of org.eclipse.jetty.toolchain:jetty-servlet-api from the Jersey test provider and from jersey-test-framework-core. The rename to jetty-servlet-api left them pointing at an artifact these Jersey jars never bring. The comment on the managed exclusion now says it is the only one. No change in what is resolved: dependency:list (test scope) is identical for all 45 modules of the reactor that builds the Jersey test users and the client modules. With the managed exclusion also removed, jakarta.servlet-api comes back in 17 of them, so that one exclusion is what keeps it out. Recognise Jetty and servlet API jars by contents, not by repository path. ClasspathTestUtils found Jetty jars and the servlet API by their Maven repository path. Under a Gradle cache (.../files-2.1/<group>/<artifact>/ <version>/<hash>/...) or a flattened lib directory nothing matched, so assertSingleJettyRelease failed with "no Jetty jars found" although Jetty was there, and a stale Jetty jar in another layout next to repository jars was not counted (review on PR apache#8699). - assertSingleJettyRelease: a jar on the classpath is a Jetty jar when it has classes under org/eclipse/jetty/, whatever its group (http2, websocket, alpn, ...); its release is the Implementation-Version (or else Bundle-Version) of its manifest. jetty-servlet-api and the orbit jars carry only javax.* classes and are not counted, so no list of groups to skip is needed. The manifest vendor is not used: Jetty 8 and 9.2 jars name the same vendor as jetty-servlet-api. - assertSingleServletApi: the one provider of javax/servlet/Servlet.class must have Bundle-SymbolicName org.eclipse.jetty.servlet-api, instead of a file name fragment. Checked outside Maven with jetty-util, jetty-server and http2-common 9.4.58 plus jetty-servlet-api 4.0.9 in a Maven layout, a Gradle cache layout and a lib directory of renamed jars: the new checks pass in all three, and fail when a jetty-http 9.2.29 or websocket-api 9.2.12 jar is added in any of them, or when javax.servlet-api 3.1.0 is added or replaces jetty-servlet-api. The old checks failed on the Gradle and renamed layouts, and missed the stale jar in the Gradle layout. In hadoop-common, TestJettyClasspath passes with this branch's poms; with trunk's poms testSingleServletApi fails, naming javax.servlet-api as the provider. Say why jetty-servlet-api is the servlet API, and what downstream projects need to do. Moving from jakarta.servlet-api / javax.servlet-api to org.eclipse.jetty.toolchain:jetty-servlet-api changes the coordinate downstream projects receive. One that also declares javax.servlet-api or jakarta.servlet-api 4.x now gets two jars with the same javax.servlet classes, because Maven cannot mediate between different coordinates (review on PR apache#8699). Comment on the managed entry in hadoop-project: jetty-servlet-api 4.0.9 is the artifact and version Jetty 12's ee8 environment manages (jetty-ee8 12.1.14, ee8.jetty.servlet.api.version), so the Jetty 12 move does not change the coordinate again; downstream projects that declare another servlet API should exclude one of them. The release note of HADOOP-19970 says the same. No change in what is resolved. Keep the classpath test support out of hadoop-client-minicluster. hadoop-client-minicluster shades hadoop-common's test jar and keeps out the test classes named Test*.class. AbstractJettyClasspathTest and ClasspathTestUtils, the support classes of the TestJettyClasspath tests, do not match that pattern, so they were shipped, unrelocated, to minicluster users. They check a module's own test classpath and are not for them: exclude both from hadoop-common in the minicluster's shade filters. Built hadoop-client-minicluster from this pom against artifacts whose hadoop-common test jar has both classes: neither is in the shaded jar; the other 52 org.apache.hadoop.test classes are still there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 1, 2026
…spath. Exclude javax.annotation:javax.annotation-api from javax-websocket-server-impl (it arrives through jetty-annotations). jakarta.annotation-api 1.3.5, already bundled through jersey-common, provides the same javax.annotation classes. Update LICENSE-binary and NOTICE-binary to list jakarta.annotation:jakarta.annotation-api:1.3.5 (EPL 2.0 + GPLv2 with classpath exception) instead of javax.annotation:javax.annotation-api:1.3.2. Add a test that the NodeManager's classpath has one javax.annotation API. The NodeManager is the module that declares javax-websocket-server-impl, whose jetty-annotations brought javax.annotation-api 1.3.2 beside jakarta.annotation-api 1.3.5, two copies of the javax.annotation classes. TestAnnotationApiClasspath checks that javax/annotation/PostConstruct.class comes from exactly one jar, jakarta.annotation-api. With trunk's poms it fails: both jars provide the class. Self-contained, so it does not depend on HADOOP-19970's ClasspathTestUtils; it was the NodeManager-only test in PR apache#8699's TestJettyClasspath. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
I'm concerned about the selection of
the above two are adopted widely, while BTW, I think allowing vendors to provide their own implementations of JSR APIs is a poor decision; having identical classes present in JARs with different |
Contributor
Author
|
@pan3793 thanks for your review. I agree that I checked the root POMs of the main downstream projects to see whether that risk is real:
Hudi, Drill, Flink and Zeppelin don't declare a servlet API in their root POM. What this shows:
So I'll switch the PR to
|
Member
|
@joseluisll, thanks for the survey, the direction sounds good to me. |
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 4, 2026
…he catalog-webapp and timelineservice-hbase tests. catalog-webapp: the tests reach Solr only through EmbeddedSolrServer, which runs no servlet container, so Solr's own Jetty (9.4.44) and servlet API do not belong on the test classpath. solr-test-framework already depends on solr-core, where EmbeddedSolrServer and NodeConfig live, so drop the direct solr-core declaration and keep solr-test-framework as the only Solr test dependency. It carries the single exclusion list: Solr's Jetty modules (jetty-io, jetty-xml, jetty-http, jetty-client, jetty-alpn-client, jetty-alpn-java-client, jetty-alpn-server, jetty-alpn-java-server, jetty-continuation, jetty-deploy, jetty-jmx, jetty-rewrite, jetty-security, jetty-servlets, http2-*), javax.servlet-api, commons-collections and jcl-over-slf4j. A Solr upgrade that adds a Jetty artifact needs one entry (review on PR apache#8699). jetty-alpn-java-client is excluded too: Solr declares 9.4.44, and the managed 9.4.58 copy won only through Maven's declaration-order tie-break via http2-http-client-transport. solr-solrj already excludes it. timelineservice-hbase-tests: on hbase-server and hbase-server:tests, exclude javax.servlet:javax.servlet-api, as hbase-server-2 already does. dependency:list (test scope) of catalog-webapp resolves 238 artifacts, solr-core 8.11.2 still at test scope, all Jetty at ${jetty.version} and no javax.servlet-api 3.1.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit c43c4e9)
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 4, 2026
…spath. Exclude javax.annotation:javax.annotation-api from javax-websocket-server-impl (it arrives through jetty-annotations). jakarta.annotation-api 1.3.5, already bundled through jersey-common, provides the same javax.annotation classes. Update LICENSE-binary and NOTICE-binary to list jakarta.annotation:jakarta.annotation-api:1.3.5 (EPL 2.0 + GPLv2 with classpath exception) instead of javax.annotation:javax.annotation-api:1.3.2. Add a test that the NodeManager's classpath has one javax.annotation API. The NodeManager is the module that declares javax-websocket-server-impl, whose jetty-annotations brought javax.annotation-api 1.3.2 beside jakarta.annotation-api 1.3.5, two copies of the javax.annotation classes. TestAnnotationApiClasspath checks that javax/annotation/PostConstruct.class comes from exactly one jar, jakarta.annotation-api. With trunk's poms it fails: both jars provide the class. Self-contained, so it does not depend on HADOOP-19970's ClasspathTestUtils; it was the NodeManager-only test in PR apache#8699's TestJettyClasspath. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 63d9fd0)
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 4, 2026
…as of 2026-11-04. The code of each PR rules. Records the 2026-11-04 rescope of HADOOP-20015 (Java only, apache#8893) and HADOOP-20016 (poms only, apache#8894), the servlet API decision (javax.servlet-api 4.0.1, plus jetty-schemas 4.0.3 on ee8) and that apache#8699 still carries jetty-servlet-api 4.0.9, the 6 port commits of apache#8704 and its stale prerequisite commits, and HADOOP-19971 (apache#8703) as jakarta preparation to land with HADOOP-19395 rather than a candidate to discard. Corrects the PR table's head/Yetus columns and the open items. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
joseluisll
force-pushed
the
jetty-phase-a
branch
from
November 4, 2026 15:35
a30da89 to
b07c423
Compare
joseluisll
changed the title
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 4, 2026
…he catalog-webapp and timelineservice-hbase tests.
catalog-webapp: on solr-core and solr-test-framework, exclude Solr's own
Jetty modules (jetty-alpn-server, jetty-alpn-java-server,
jetty-continuation, jetty-deploy, jetty-jmx, jetty-rewrite,
jetty-security, jetty-servlets, http2-server) and javax.servlet-api.
The tests reach Solr only through EmbeddedSolrServer, so only
${jetty.version} stays on the test classpath.
timelineservice-hbase-tests: on hbase-server and hbase-server:tests,
exclude javax.servlet:javax.servlet-api, as hbase-server-2 already does.
Also exclude jetty-alpn-java-client from solr-core and solr-test-framework.
Both Solr artifacts declare jetty-alpn-java-client 9.4.44. The managed
9.4.58 copy won only through Maven's declaration-order tie-break via
http2-http-client-transport. Exclude it, as solr-solrj already does.
Declare the Solr exclusions once, in catalog-webapp's dependencyManagement.
solr-core and solr-test-framework carried the same 22 exclusions, so a Solr
upgrade that adds a Jetty artifact had to be fixed in both places, and
missing one would bring back a second Jetty release (review on PR apache#8699).
They now live once, in a dependencyManagement section local to
hadoop-yarn-applications-catalog-webapp, with the Solr version; the two
test-scope dependencies only name the artifacts.
Local rather than in hadoop-project: only this module uses Solr, and it
keeps the change out of the root pom.
No change in what the module resolves: dependency:list (test scope) gives
the same 238 artifacts before and after, all Jetty at ${jetty.version} and
no javax.servlet-api 3.1.0.
Keep a single Solr exclusion list, on solr-test-framework.
The previous change moved both Solr artifacts into a local
dependencyManagement, but solr-core and solr-test-framework still each
carried the same 22 exclusions, so the list was not declared once.
The tests use solr-core only through EmbeddedSolrServer and NodeConfig,
and solr-test-framework already depends on solr-core. Drop the direct
solr-core declaration and the local dependencyManagement, and declare
solr-test-framework (test scope) once, with the only exclusion list.
The resolved test classpath of catalog-webapp is unchanged: the same
238 artifacts, solr-core 8.11.2 still at test scope, and no
javax.servlet-api 3.1.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 4, 2026
…spath. Exclude javax.annotation:javax.annotation-api from javax-websocket-server-impl (it arrives through jetty-annotations). jakarta.annotation-api 1.3.5, already bundled through jersey-common, provides the same javax.annotation classes. Update LICENSE-binary and NOTICE-binary to list jakarta.annotation:jakarta.annotation-api:1.3.5 (EPL 2.0 + GPLv2 with classpath exception) instead of javax.annotation:javax.annotation-api:1.3.2. Add a test that the NodeManager's classpath has one javax.annotation API. The NodeManager is the module that declares javax-websocket-server-impl, whose jetty-annotations brought javax.annotation-api 1.3.2 beside jakarta.annotation-api 1.3.5, two copies of the javax.annotation classes. TestAnnotationApiClasspath checks that javax/annotation/PostConstruct.class comes from exactly one jar, jakarta.annotation-api. With trunk's poms it fails: both jars provide the class. Self-contained, so it does not depend on HADOOP-19970's ClasspathTestUtils; it was the NodeManager-only test in PR apache#8699's TestJettyClasspath. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
joseluisll
added a commit
to joseluisll/hadoop
that referenced
this pull request
Nov 4, 2026
javax.servlet:javax.servlet-api 3.1.0 and jakarta.servlet:jakarta.servlet-api 4.0.4 both publish the javax.servlet packages, and which one a module compiles and runs against depends on jar order. Leave one servlet API jar: org.eclipse.jetty.toolchain:jetty-servlet-api, the one Jetty 12's ee8 environment depends on. * hadoop-project: add jetty-servlet-api.version (4.0.9) and manage org.eclipse.jetty.toolchain:jetty-servlet-api in place of jakarta.servlet:jakarta.servlet-api 4.0.4. * hadoop-common: declare jetty-servlet-api at compile scope. HttpServer2 and its filters compile against javax.servlet, which today arrives only as javax.servlet-api 3.1.0 through jetty-server; the modules that use javax.servlet without declaring an API get it through hadoop-common. * hadoop-project and hadoop-sls: the exclusion on jetty-server named org.eclipse.jetty:javax.servlet-api, a coordinate that matches nothing. It now names javax.servlet:javax.servlet-api. * hadoop-project: on javax-websocket-server-impl, also exclude javax.servlet:javax.servlet-api (through websocket-servlet). * The 17 module poms that declare the servlet API, and the 5 exclusions of it (4 in hadoop-client-minicluster, 1 in hadoop-yarn-common), move to the new coordinate. * hadoop-project: jersey-test-framework-core declares jakarta.servlet-api at compile scope; exclude it there and on the Jersey test provider. * LICENSE-binary: replace jakarta.servlet:jakarta.servlet-api:4.0.4 with org.eclipse.jetty.toolchain:jetty-servlet-api:4.0.9 (Apache License 2.0 / EPL 2.0, like the other Jetty artifacts). * LICENSE-binary and NOTICE-binary: drop javax.servlet:javax.servlet-api. No Jetty version change. jetty-servlet-api and jakarta.servlet-api 4.0.4 ship the same javax.servlet 4.0 classes, a superset of 3.1, and Jetty 9.4 runs on Servlet 4.0. Downstream: non-shaded artifacts now bring the servlet API as org.eclipse.jetty.toolchain:jetty-servlet-api instead of jakarta.servlet:jakarta.servlet-api, so exclusions of the old coordinate need the new one; direct consumers of hadoop-common get jetty-servlet-api 4.0.9 instead of javax.servlet-api 3.1.0. hadoop-client-runtime still relocates one servlet API, now taken from jetty-servlet-api. Add classpath tests for one servlet API and one Jetty release. hadoop-common, the shuffle handler, yarn-common, the ApplicationHistoryServer, the NodeManager and the Router each get a TestJettyClasspath that checks their test classpath: javax/servlet/Servlet.class comes from exactly one jar, jetty-servlet-api, and every Jetty jar is from the same release. Following the review on PR apache#8699: * The tests live once, in AbstractJettyClasspathTest in hadoop-common's test jar, which every one of these modules already depends on. Each module's TestJettyClasspath is an empty subclass; JUnit 5 runs the inherited tests, so the modules cannot drift apart. * ClasspathTestUtils recognises Jetty jars by the Maven repository layout, .../org/eclipse/jetty/[group/...]artifact/version/artifact-version.jar, in any Jetty group, so stale http2, fcgi or websocket jars beside ${jetty.version} fail the test. The groups whose artifacts are versioned on their own (toolchain, alpn, orbit) are left out. With trunk's poms, testSingleServletApi fails in hadoop-common: javax.servlet-api 3.1.0 provides javax/servlet/Servlet.class. Exclude the jakarta.servlet-api of the Jersey test framework only once. jersey-test-framework-core brings the servlet API as jakarta.servlet:jakarta.servlet-api, and the managed jersey-test-framework-core in hadoop-project already excludes it. Managed exclusions also apply where core arrives transitively and where it is declared with exclusions of its own, so the other declarations were redundant or dead (review on PR apache#8699): - hadoop-project: drop the jakarta.servlet-api exclusion repeated on the managed jersey-test-framework-provider-jetty. - hadoop-yarn-common and hadoop-client-minicluster: drop the exclusions of org.eclipse.jetty.toolchain:jetty-servlet-api from the Jersey test provider and from jersey-test-framework-core. The rename to jetty-servlet-api left them pointing at an artifact these Jersey jars never bring. The comment on the managed exclusion now says it is the only one. No change in what is resolved: dependency:list (test scope) is identical for all 45 modules of the reactor that builds the Jersey test users and the client modules. With the managed exclusion also removed, jakarta.servlet-api comes back in 17 of them, so that one exclusion is what keeps it out. Recognise Jetty and servlet API jars by contents, not by repository path. ClasspathTestUtils found Jetty jars and the servlet API by their Maven repository path. Under a Gradle cache (.../files-2.1/<group>/<artifact>/ <version>/<hash>/...) or a flattened lib directory nothing matched, so assertSingleJettyRelease failed with "no Jetty jars found" although Jetty was there, and a stale Jetty jar in another layout next to repository jars was not counted (review on PR apache#8699). - assertSingleJettyRelease: a jar on the classpath is a Jetty jar when it has classes under org/eclipse/jetty/, whatever its group (http2, websocket, alpn, ...); its release is the Implementation-Version (or else Bundle-Version) of its manifest. jetty-servlet-api and the orbit jars carry only javax.* classes and are not counted, so no list of groups to skip is needed. The manifest vendor is not used: Jetty 8 and 9.2 jars name the same vendor as jetty-servlet-api. - assertSingleServletApi: the one provider of javax/servlet/Servlet.class must have Bundle-SymbolicName org.eclipse.jetty.servlet-api, instead of a file name fragment. Checked outside Maven with jetty-util, jetty-server and http2-common 9.4.58 plus jetty-servlet-api 4.0.9 in a Maven layout, a Gradle cache layout and a lib directory of renamed jars: the new checks pass in all three, and fail when a jetty-http 9.2.29 or websocket-api 9.2.12 jar is added in any of them, or when javax.servlet-api 3.1.0 is added or replaces jetty-servlet-api. The old checks failed on the Gradle and renamed layouts, and missed the stale jar in the Gradle layout. In hadoop-common, TestJettyClasspath passes with this branch's poms; with trunk's poms testSingleServletApi fails, naming javax.servlet-api as the provider. Say why jetty-servlet-api is the servlet API, and what downstream projects need to do. Moving from jakarta.servlet-api / javax.servlet-api to org.eclipse.jetty.toolchain:jetty-servlet-api changes the coordinate downstream projects receive. One that also declares javax.servlet-api or jakarta.servlet-api 4.x now gets two jars with the same javax.servlet classes, because Maven cannot mediate between different coordinates (review on PR apache#8699). Comment on the managed entry in hadoop-project: jetty-servlet-api 4.0.9 is the artifact and version Jetty 12's ee8 environment manages (jetty-ee8 12.1.14, ee8.jetty.servlet.api.version), so the Jetty 12 move does not change the coordinate again; downstream projects that declare another servlet API should exclude one of them. The release note of HADOOP-19970 says the same. No change in what is resolved. Keep the classpath test support out of hadoop-client-minicluster. hadoop-client-minicluster shades hadoop-common's test jar and keeps out the test classes named Test*.class. AbstractJettyClasspathTest and ClasspathTestUtils, the support classes of the TestJettyClasspath tests, do not match that pattern, so they were shipped, unrelocated, to minicluster users. They check a module's own test classpath and are not for them: exclude both from hadoop-common in the minicluster's shade filters. Built hadoop-client-minicluster from this pom against artifacts whose hadoop-common test jar has both classes: neither is in the shaded jar; the other 52 org.apache.hadoop.test classes are still there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…he catalog-webapp and timelineservice-hbase tests. catalog-webapp: the tests reach Solr only through EmbeddedSolrServer, which runs no servlet container, so Solr's own Jetty (9.4.44) and servlet API do not belong on the test classpath. solr-test-framework already depends on solr-core, where EmbeddedSolrServer and NodeConfig live, so drop the direct solr-core declaration and keep solr-test-framework as the only Solr test dependency. It carries the single exclusion list: Solr's Jetty modules (jetty-io, jetty-xml, jetty-http, jetty-client, jetty-alpn-client, jetty-alpn-java-client, jetty-alpn-server, jetty-alpn-java-server, jetty-continuation, jetty-deploy, jetty-jmx, jetty-rewrite, jetty-security, jetty-servlets, http2-*), javax.servlet-api, commons-collections and jcl-over-slf4j. A Solr upgrade that adds a Jetty artifact needs one entry (review on PR apache#8699). jetty-alpn-java-client is excluded too: Solr declares 9.4.44, and the managed 9.4.58 copy won only through Maven's declaration-order tie-break via http2-http-client-transport. solr-solrj already excludes it. timelineservice-hbase-tests: on hbase-server and hbase-server:tests, exclude javax.servlet:javax.servlet-api, as hbase-server-2 already does. dependency:list (test scope) of catalog-webapp resolves 238 artifacts, solr-core 8.11.2 still at test scope, all Jetty at ${jetty.version} and no javax.servlet-api 3.1.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…Jetty. Switch JerseyTest from jersey-test-framework-provider-jetty to jersey-test-framework-provider-jdk-http. Jersey 2 has no container for Jetty 12, so this has to land before the Jetty 12 upgrade (HADOOP-19972). Production HTTP is untouched; HttpServer2 stays on Jetty 9.4. * hadoop-project: manage provider-jdk-http in place of provider-jetty, keeping the javax.servlet-api exclusion. * Module poms: switch the artifactId. * hadoop-client-minicluster: bundle the jdk-http provider; declare jetty-util directly as optional, since its only copy used to arrive through provider-jetty; do not relocate the JDK's com/sun/net/httpserver classes. * LICENSE-binary: update the provider entry. Address review: list jersey-container-jdk-http, fix stale comment. * LICENSE-binary: add jersey-container-jdk-http, which the jdk-http provider brings in and hadoop-client-minicluster bundles. * hadoop-client-minicluster: the "jetty-util is in client" comment is stale; hadoop-client-runtime does not shade it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…spath. Exclude javax.annotation:javax.annotation-api from javax-websocket-server-impl (it arrives through jetty-annotations). jakarta.annotation-api 1.3.5, already bundled through jersey-common, provides the same javax.annotation classes. Update LICENSE-binary and NOTICE-binary to list jakarta.annotation:jakarta.annotation-api:1.3.5 (EPL 2.0 + GPLv2 with classpath exception) instead of javax.annotation:javax.annotation-api:1.3.2. Add a test that the NodeManager's classpath has one javax.annotation API. The NodeManager is the module that declares javax-websocket-server-impl, whose jetty-annotations brought javax.annotation-api 1.3.2 beside jakarta.annotation-api 1.3.5, two copies of the javax.annotation classes. TestAnnotationApiClasspath checks that javax/annotation/PostConstruct.class comes from exactly one jar, jakarta.annotation-api. With trunk's poms it fails: both jars provide the class. Self-contained, so it does not depend on HADOOP-19970's ClasspathTestUtils; it was the NodeManager-only test in PR apache#8699's TestJettyClasspath. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Jetty 10 and later drop org.eclipse.jetty.util.log.Log, and Jetty 12 drops ConcurrentHashSet and MultiException. Stop using them and two other Jetty types the code did not need: - FSMainOperationsBaseTest, ViewFileSystemTestSetup, ViewFsTestSetup, TestAuthenticationSessionCookie, TestAMRMClient, TestYarnCLI, TestRollingLevelDBTimelineStore and MockNM log through SLF4J instead of Jetty's Log. - TestDockerCommandExecutor has its own logger instead of borrowing GzipHttpOutputInterceptor's. - FederationInterceptor uses ConcurrentHashMap.newKeySet() instead of Jetty's ConcurrentHashSet. - TestLogAggregationService batches its assertion failures in a list and throws one AssertionError carrying all of them, instead of using Jetty's MultiException. - HttpServer2#inferMimeType calls ServletContext#getMimeType directly instead of casting to a Jetty context type. No change on Jetty 9.4. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
These modules import Jetty classes but only received the artifacts
transitively. Declare them, so each module states the Jetty it uses
directly through the Jetty 12 ee8 upgrade and the later jakarta
migration, where hadoop-common may stop exporting some of them:
- hadoop-project: manage jetty-http and jetty-io at ${jetty.version}.
- hadoop-common, hadoop-mapreduce-client-shuffle, hadoop-hdfs-httpfs:
declare jetty-http as optional. hadoop-sls: declare it provided, like
its jetty-server.
- yarn-common, applicationhistoryservice, resourcemanager, router:
declare jetty-webapp, and jetty-servlet in applicationhistoryservice.
- hadoop-hdfs: declare jetty-io as optional.
- hadoop-hdfs-httpfs: declare jetty-servlet, and jetty-util as
optional.
- hadoop-mapreduce-client-jobclient: declare jetty-server and
jetty-servlet, provided.
- nodemanager: declare jetty-servlet.
- router: declare jetty-server, jetty-servlet and jetty-util.
- web-proxy: declare jetty-servlet, provided, and jetty-util.
jetty-http is optional so that what downstream projects resolve does not
change. At compile scope, Maven's nearest-wins mediation changed it: a
downstream project with jetty-client 9.4.40 next to hadoop-common
resolved jetty-http 9.4.58 instead of 9.4.40. jetty-io in hadoop-hdfs
and jetty-util in hadoop-hdfs-httpfs reached those modules only through
jetty-server, and are optional for the same reason.
Every declaration uses the scope the module already resolved the
artifact at, so each module's dependency tree is unchanged: the same
Jetty artifacts, versions and scopes.
No version change on Jetty 9.4.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
javax.servlet:javax.servlet-api 3.1.0 and jakarta.servlet:jakarta.servlet-api 4.0.4 both publish the javax.servlet packages, and which one a module compiles and runs against depends on jar order. Leave one servlet API jar: javax.servlet:javax.servlet-api 4.0.1. That coordinate only ever carries the javax.servlet namespace, so Maven mediates it safely against the javax.servlet-api that Jetty 9.4 and downstream projects (Hive, HBase, Phoenix, Ranger, Livy; Spark and Kyuubi manage 4.0.1) declare. jakarta.servlet-api moved to the jakarta.servlet namespace in 5.0, and projects that pin it at 5.x/6.x in dependencyManagement would silently replace a jakarta.servlet-api 4.x of Hadoop's and drop its javax.servlet classes; that coordinate is left for the move to jakarta.servlet (HADOOP-19395). * hadoop-project: add javax.servlet-api.version (4.0.1) and manage javax.servlet:javax.servlet-api in place of jakarta.servlet:jakarta.servlet-api 4.0.4. The managed version also applies to the javax.servlet-api 3.1.0 that jetty-server and javax-websocket-server-impl bring, so no exclusion is needed for them. * hadoop-project and hadoop-sls: drop the exclusion on jetty-server of org.eclipse.jetty:javax.servlet-api, a coordinate that matches nothing. * hadoop-common: declare javax.servlet-api at compile scope. HttpServer2 and its filters compile against javax.servlet, which so far arrived only transitively, through jetty-server; the modules that use javax.servlet without declaring an API get it through hadoop-common. * The 17 module poms that declared jakarta.servlet-api move to javax.servlet-api. hadoop-client-minicluster drops its 4 exclusions of jakarta.servlet-api, and hadoop-yarn-common its exclusion on the Jersey test provider: nothing brings it any more (see below). hadoop-client already excludes javax.servlet-api from hadoop-common, now the API that module declares. * hadoop-project: jersey-test-framework-core declares jakarta.servlet-api 4.x at compile scope; exclude it on the managed entry. Managed exclusions also apply where core arrives transitively (the Jersey test provider) and where it is declared with exclusions of its own (hadoop-client-minicluster), so the exclusion repeated on the managed Jersey test provider goes. * LICENSE-binary: javax.servlet:javax.servlet-api 3.1.0 becomes 4.0.1 (CDDL 1.1 + GPLv2 with classpath exception, as before); drop jakarta.servlet:jakarta.servlet-api:4.0.4. Add classpath tests for one servlet API and one Jetty release: AbstractJettyClasspathTest in hadoop-common's test jar, with an empty TestJettyClasspath subclass in hadoop-common, the shuffle handler, yarn-common, the ApplicationHistoryServer, the NodeManager and the Router, so the modules cannot drift apart. ClasspathTestUtils recognises jars by their contents and manifests, not by repository path, so the checks hold in a Maven repository, a Gradle cache or a flattened lib directory: * testSingleServletApi: exactly one jar provides javax/servlet/Servlet.class, with Bundle-SymbolicName javax.servlet-api and Specification-Version 4.0 (javax.servlet-api 3.1.0 has the same symbolic name). * testSingleJettyRelease: every jar with classes under org/eclipse/jetty/, whatever its group, has the same Implementation-Version (or else Bundle-Version). The servlet API and the orbit jars carry only javax.* classes and are not counted. hadoop-client-minicluster keeps AbstractJettyClasspathTest and ClasspathTestUtils out of its shaded jar: they are not named Test*.class, and they check a module's own test classpath, not a minicluster user's. No Jetty version change. javax.servlet-api 4.0.1 and jakarta.servlet-api 4.0.4 ship the same javax.servlet 4.0 classes, a superset of 3.1, and Jetty 9.4 runs on Servlet 4.0. Tests: mvn install -DskipTests; dependency:tree of hadoop-common, hadoop-hdfs, hadoop-yarn-common, the NodeManager, the ResourceManager, hadoop-kms and hadoop-client shows javax.servlet-api 4.0.1 as the only servlet API, and dependency:list over the whole reactor shows no jakarta.servlet-api, jetty-servlet-api or other javax.servlet-api version. hadoop-client-check-invariants and hadoop-client-check-test-invariants pass. testSingleServletApi passes in every module with a TestJettyClasspath. Downstream: direct users of hadoop-common move from javax.servlet-api 3.1.0 to 4.0.1 on the same coordinate. Non-shaded artifacts no longer bring jakarta.servlet:jakarta.servlet-api 4.0.4; projects that declared or excluded it on Hadoop artifacts need javax.servlet:javax.servlet-api. hadoop-client-runtime still relocates one servlet API, now taken from javax.servlet-api. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The previous Jenkins build (PR-8699/31) aborted during 'setup sources' with a git pack permission error before precommit ran, so no results were produced. Co-Authored-By: Claude Code <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
Note
Stacked PR: please review only the last commit, HADOOP-19970.
This branch carries the Jetty 12 phase A changes it depends on, in merge order, so that CI tests them together. The first five commits are reviewed in their own PRs and have the same content there:
TestJettyClasspath#testSingleJettyReleasefails on thejetty-continuation9.4.55 that the Jersey Jetty test provider brings)Once those are merged, this branch will be rebased onto trunk and only the HADOOP-19970 commit will remain.
This PR leaves one servlet API on every module classpath and moves it to
javax.servlet:javax.servlet-api4.0.1.javax.servlet:javax.servlet-api3.1.0 (throughjetty-server) andjakarta.servlet:jakarta.servlet-api4.0.4 both publish thejavax.servletpackages, so which one a module compiles and runs against depends on jar order. This managesjavax.servlet:javax.servlet-api4.0.1 inhadoop-projectand dropsjakarta.servlet-api4.0.4 from Hadoop.javax.servlet:javax.servlet-apiis the coordinate most downstream projects already declare (Hive, HBase, Phoenix, Ranger, Livy, and Spark and Kyuubi manage 4.0.1), so Maven mediates Hadoop's 4.0.1 with theirs, whileorg.eclipse.jetty.toolchain:jetty-servlet-apiis used by almost none of them (Ozone is the exception) and would leave two copies of the same classes. A project that pinsjakarta.servlet-apiat 5.x/6.x independencyManagementwould instead silently replace Hadoop's 4.x and lose thejavax.servletclasses, so that coordinate is left for the move tojakarta.servlet(HADOOP-19395). Thejetty-schemasaddition that Jetty 12 ee8 needs for itsweb.xmlschemas is part of HADOOP-19972, not this PR.hadoop-project: addjavax.servlet-api.version(4.0.1), managejavax.servlet:javax.servlet-apiin place ofjakarta.servlet:jakarta.servlet-api4.0.4, and comment on why, and on what downstream projects need to do. The managed version also replaces thejavax.servlet-api3.1.0 that Jetty 9.4 depends on, so no exclusion is needed for it.hadoop-projectandhadoop-sls: drop the exclusion onjetty-serveroforg.eclipse.jetty:javax.servlet-api, a coordinate that matches nothing.hadoop-common: declarejavax.servlet-api(compile).HttpServer2and its filters compile againstjavax.servlet, which today arrives only transitively, throughjetty-server; the modules that usejavax.servletwithout declaring an API get it throughhadoop-common.jakarta.servlet-apimove tojavax.servlet-api.hadoop-client-miniclusterdrops its 4 exclusions ofjakarta.servlet-api, andhadoop-yarn-commonits exclusion on the Jersey test provider: nothing brings it any more.hadoop-clientalready excludesjavax.servlet-apifromhadoop-common, now the API that module declares.hadoop-project:jersey-test-framework-coredeclaresjakarta.servlet-api4.x at compile scope. Exclude it on the managed entry; managed exclusions also apply where core arrives transitively (the Jersey test provider) and where it is declared with exclusions of its own (hadoop-client-minicluster), so the exclusion repeated on the managed Jersey test provider goes.LICENSE-binary:javax.servlet:javax.servlet-api3.1.0 becomes 4.0.1 (CDDL 1.1 + GPLv2 with classpath exception, as before), andjakarta.servlet:jakarta.servlet-api:4.0.4drops out.AbstractJettyClasspathTest(hadoop-common test jar), with an emptyTestJettyClasspathsubclass in hadoop-common, the shuffle handler, yarn-common, the ApplicationHistoryServer, the NodeManager and the Router.testSingleServletApichecks that exactly one jar providesjavax/servlet/Servlet.class, withBundle-SymbolicNamejavax.servlet-apiandSpecification-Version4.0 (javax.servlet-api3.1.0 has the same symbolic name).testSingleJettyReleasechecks that every jar with classes underorg/eclipse/jetty/, whatever its group, has the sameImplementation-Version(or elseBundle-Version); the servlet API and the orbit jars carry onlyjavax.*classes and are not counted.ClasspathTestUtilsrecognises jars by their contents and manifests, not by repository path, so the checks hold in a Maven repository, a Gradle cache or a flattened lib directory.hadoop-client-miniclusterkeepsAbstractJettyClasspathTestandClasspathTestUtilsout of its shaded jar: they are not namedTest*.class, and they check a module's own test classpath, not a minicluster user's.No Jetty version change.
javax.servlet-api4.0.1 andjakarta.servlet-api4.0.4 ship the samejavax.servlet4.0 classes, a superset of 3.1, and Jetty 9.4 runs on Servlet 4.0.Downstream: direct users of
hadoop-commonmove fromjavax.servlet-api3.1.0 to 4.0.1 on the same coordinate, mediated by Maven. Non-shaded artifacts no longer bringjakarta.servlet:jakarta.servlet-api4.0.4, so projects that declared or excluded it on Hadoop artifacts needjavax.servlet:javax.servlet-apiinstead; the JIRA has a release note.hadoop-client-runtimestill relocates one servlet API, now taken fromjavax.servlet-api.How was this patch tested?
TestJettyClasspathis added in hadoop-common, the shuffle handler, yarn-common, the ApplicationHistoryServer, the NodeManager and the Router;testSingleServletApiandtestSingleJettyReleaserun there with the rest of each module's tests.For code changes:
javax.servlet-apiwas already bundled at 3.1.0 and moves to 4.0.1, CDDL 1.1 + GPLv2 with classpath exception; thejakarta.servlet-api4.0.4 entry is removed)LICENSE,LICENSE-binary,NOTICE-binaryfiles?AI Tooling
Contains content generated by Claude.
If an AI tool was used: