[
https://issues.apache.org/jira/browse/HADOOP-19970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119062#comment-18119062
]
ASF GitHub Bot commented on HADOOP-19970:
-----------------------------------------
joseluisll commented on PR #8699:
URL: https://github.com/apache/hadoop/pull/8699#issuecomment-5828510492
The "Test mr" job fails on TestRuntimeEstimators. It is not caused by this
PR's
code: TaskId.hashCode() depends on the JVM's identity hash of the TaskType
enum,
and this PR's classpath change happens to shift it into an order the test
cannot handle. Tracked and fixed in MAPREDUCE-7545 (apache/hadoop#8754).
> Resolve a single Jetty release and servlet API on every module classpath
> ------------------------------------------------------------------------
>
> Key: HADOOP-19970
> URL: https://issues.apache.org/jira/browse/HADOOP-19970
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: build, common, test
> Reporter: Jose Luis López
> Assignee: Jose Luis López
> Priority: Major
> Labels: pull-request-available
>
> Several modules resolve more than one Jetty release, and more than one servlet
> API, on a single classpath. Both combinations compile and then fail at run
> time,
> on whichever code path reaches the wrong jar.
> Intended result:
> * Every module resolves one Jetty release. Three are in play today: 9.4.44
> and
> 9.4.55 reach some classpaths beside the managed 9.4.58. They arrive with
> solr-core in the app catalog webapp's tests, and with Jersey's Jetty test
> container, which Jersey 2.46 builds against 9.4.55.
> * Every module resolves one servlet API, jakarta.servlet:jakarta.servlet-api
> 4.0.4, the one hadoop-project already manages.
> javax.servlet:javax.servlet-api
> publishes the same javax.servlet packages, and 73 modules carry both, so
> which
> one a module compiles and runs against is decided by the order of the jars
> rather than by anything in a pom.
> * Every module that uses Jetty in its main sources declares it. Four do not,
> and compile only because some other dependency happens to supply it. Three
> of them now declare what they use. The fourth, hadoop-mapreduce-client-app,
> used Jetty only for logging in JobEndNotifier, which MAPREDUCE-7544 moved
> to
> SLF4J.
> * The Jersey test framework no longer runs on Jetty. Its Jetty container is
> built against Jetty 9 and has no Jetty 12 counterpart for javax.servlet, so
> tests move to Jersey's JDK HTTP server container, which adds no Jetty and
> no
> servlet API to any classpath.
> * The shaded client keeps shipping jetty-util. Once Jersey's test container
> is
> off Jetty, nothing carries it into hadoop-client-minicluster, which
> excludes
> it on the grounds that hadoop-client-runtime ships it. The runtime jar
> ships
> it again, as it did before YARN-11793.
> One module keeps two servlet APIs:
> hadoop-yarn-server-timelineservice-hbase-tests,
> where the second arrives with HBase's own test stack.
> Out of scope:
> * The servlet API coordinate. It stays jakarta.servlet:jakarta.servlet-api.
> Which coordinate the Jetty 12 ee8 artifacts should resolve to is decided in
> HADOOP-19972.
> * The JSP API. hadoop-common keeps declaring jakarta.servlet.jsp-api, since
> downstream projects inherit it.
> * The Jetty version. None of this depends on a Jetty version change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
