[
https://issues.apache.org/jira/browse/HADOOP-19971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jose Luis López updated HADOOP-19971:
-------------------------------------
Parent: HADOOP-19912
Issue Type: Sub-task (was: Task)
> Remove servlet and Jetty types from classes that do not need them
> -----------------------------------------------------------------
>
> Key: HADOOP-19971
> URL: https://issues.apache.org/jira/browse/HADOOP-19971
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: auth, common
> Reporter: Jose Luis López
> Priority: Minor
>
> WHY
> ===
> Hadoop will eventually move from the javax.servlet namespace to
> jakarta.servlet. When it does, every class that mentions a servlet type has to
> be revisited, and every class that mentions a Jetty type has to be revisited
> again when the Jetty API changes underneath it.
> Several of those classes have no real connection to either. A component that
> generates signing secrets was handed the web server's context even though it
> only wanted somewhere to stash an object. A certificate parser reported a bad
> certificate as a web server error. A file-transfer handler built on Netty
> borrowed two header names from Jetty.
> This clears those cases out. The later migration is smaller, and the classes
> concerned stop being part of it at all.
> WHAT CHANGES FOR ANYONE USING HADOOP
> ====================================
> Nothing. Nothing is removed, nothing changes shape, and no dependency, version
> or setting changes. Code built against today's release keeps compiling and
> keeps running without being rebuilt.
> Two entry points were the awkward ones. Both stay exactly as they are, marked
> deprecated, with a cleaner alternative alongside. Projects that adopt the new
> one are unaffected when the namespace finally moves; projects that do not are
> no worse off than today. A test suite exists purely to prove the old path
> still
> behaves - including the awkward case of a plugin that extends Hadoop's rolling
> secret provider and calls up into it.
> The shuffle protocol is untouched, byte for byte. Deployments see no
> difference.
> WHAT CHANGES INSIDE
> ===================
> before after
> modules using Jetty in main sources 13 12
> main-source files using Jetty 25 23
> hadoop-auth main classes naming a servlet 14 11
> The MapReduce shuffle module stops depending on Jetty altogether, in code and
> in its build file.
> In hadoop-auth, the secret providers and the authentication token no longer
> mention the servlet API. They are initialised instead against a small,
> two-method store that holds whatever needs sharing - which is all the one
> provider that used the servlet context was ever doing with it. One new class
> does mention the servlet API, and exists solely to keep the old path working.
> The YARN services client and the shuffle handler each replaced a small Jetty
> utility with the equivalent from the JDK or from Netty, which they already
> depend on.
> WHAT THIS DOES NOT DO
> =====================
> No namespace change, no Jetty upgrade, no Jersey change, no EE environments.
> The tree stays on Jetty 9.4, Jersey 2 and javax.servlet throughout.
> The authentication handler classes still mention the servlet API,
> deliberately.
> They sit on the extension point that HBase, Hive, Spark, Ozone and Knox build
> against, and changing it is precisely the kind of break this issue is designed
> to avoid. It belongs with the namespace change, where downstream projects are
> expecting it.
> DEPENDS ON
> ==========
> HADOOP-19970 (PR #8699), for sequencing only. That PR declares a Jetty
> artifact
> for the shuffle module; this one removes the last use of it, and drops the
> declaration in the same change.
> 16 files changed. Works whether HADOOP-19912 ends up going through Jetty 12's
> ee8 environment or straight to ee10, and commits the project to neither.
> Contains content generated by Claude.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
