[
https://issues.apache.org/jira/browse/HADOOP-19970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118936#comment-18118936
]
ASF GitHub Bot commented on HADOOP-19970:
-----------------------------------------
joseluisll commented on code in PR #8699:
URL: https://github.com/apache/hadoop/pull/8699#discussion_r4097691775
##########
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/JobEndNotifier.java:
##########
@@ -141,24 +145,24 @@ protected boolean notifyURLOnce() {
private boolean notifyViaBuiltInNotifier() {
boolean success = false;
try {
- Log.getLog().info("Job end notification trying " + urlToNotify);
+ LOG.info("Job end notification trying " + urlToNotify);
HttpURLConnection conn =
(HttpURLConnection) urlToNotify.openConnection(proxyToUse);
conn.setConnectTimeout(timeout);
conn.setReadTimeout(timeout);
conn.setAllowUserInteraction(false);
if(conn.getResponseCode() != HttpURLConnection.HTTP_OK) {
- Log.getLog().warn("Job end notification to " + urlToNotify
+ LOG.warn("Job end notification to " + urlToNotify
+ " failed with code: " + conn.getResponseCode() + " and message
\""
+ conn.getResponseMessage() + "\"");
}
else {
success = true;
- Log.getLog().info("Job end notification to " + urlToNotify
+ LOG.info("Job end notification to " + urlToNotify
Review Comment:
Agreed on both counts. I have filed MAPREDUCE-7544 for the SLF4J switch and
it is being prepared as a separate PR, with the `{}` placeholder style applied,
so it can be reviewed and backported on its own as you suggested.
I will drop the change from this PR and rebase on top of MAPREDUCE-7544 once
it lands. `hadoop-mapreduce-client-app` then needs no Jetty declaration at all,
since JobEndNotifier is its only Jetty reference in main sources — which is
what your question on the pom was really pointing at.
Eight test classes still use the same Jetty logging facade (four in
hadoop-common, two in hadoop-yarn-client, one each in
hadoop-yarn-server-applicationhistoryservice and
hadoop-yarn-server-resourcemanager). I have left those out to keep
MAPREDUCE-7544 small enough to backport cleanly; happy to do them as a
follow-up.
> 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
> 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.
> * Every module resolves one servlet API. javax.servlet:javax.servlet-api and
> jakarta.servlet:jakarta.servlet-api both publish the 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.
> * The unused JSP API is gone. It reaches around eighty-five classpaths
> through
> hadoop-common, and nothing in the tree uses JSP.
> One module keeps two servlet APIs:
> hadoop-yarn-server-timelineservice-hbase-tests,
> where the second arrives with HBase's own test stack.
> 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]
