[
https://issues.apache.org/jira/browse/HADOOP-19970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jose Luis López updated HADOOP-19970:
-------------------------------------
Description:
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,
org.eclipse.jetty.toolchain:jetty-servlet-api
4.0.9, the artifact Jetty 12's ee8 environment depends on. hadoop-project
manages it in place of jakarta.servlet:jakarta.servlet-api 4.0.4. That
artifact and javax.servlet:javax.servlet-api publish the same javax.servlet
packages, and 73 modules carry more than one of them, so which one a module
compiles and runs against is decided by the order of the jars rather than by
anything in a pom. Settling on the ee8 artifact now means HADOOP-19972 does
not change the coordinate a second time.
* 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 to any
classpath. Its jakarta.servlet-api dependency is excluded.
* 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 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.
was:
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.
> 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,
> org.eclipse.jetty.toolchain:jetty-servlet-api
> 4.0.9, the artifact Jetty 12's ee8 environment depends on. hadoop-project
> manages it in place of jakarta.servlet:jakarta.servlet-api 4.0.4. That
> artifact and javax.servlet:javax.servlet-api publish the same javax.servlet
> packages, and 73 modules carry more than one of them, so which one a module
> compiles and runs against is decided by the order of the jars rather than
> by
> anything in a pom. Settling on the ee8 artifact now means HADOOP-19972 does
> not change the coordinate a second time.
> * 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 to
> any
> classpath. Its jakarta.servlet-api dependency is excluded.
> * 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 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]
