CentOS 8 安装 Apache XML Commons Resolver 指南

目标：在 CentOS 8 上从零搭建 Apache XML Commons Resolver 1.2 的开发与运行环境（JDK 17 + Maven 3.5.4 + 中央仓库依赖），修复 CentOS 8 停维后的软件源，跑通「不带 catalog 解析失败 → 带 catalog 离线解析成功」的最小验证，并排掉 el8 特有的 JDK8 回落与 JAVA_HOME 两大坑；本文全部命令与回显均已在 CentOS 8 实测通过。

Apache XML Commons Resolver（xml-commons 子项目的 Resolver 组件）是 OASIS XML Catalog 标准的 Java 实现：把 XML 文档里的 DTD/XSD 外部引用映射到本地 catalog 文件登记的本地资源，让解析器离线完成实体解析。它与 Ubuntu 上的安装逻辑完全一致（组件部分见第 1 篇《Ubuntu 22.04 安装 Apache XML Commons Resolver 指南》），差异集中在系统层：CentOS 8 已于 2021-12-31 停止维护，官方源下线，必须先修复软件源；el8 仓库里的 Maven 会连带安装 JDK 8，且 Maven 脚本定位 JDK 的方式与 Debian 系不同，JAVA_HOME 必须显式设置。本文按 CentOS 8 的真实情况给出两种落地方式：Maven 依赖方案与 jar 直用方案。

一、环境信息

本节先固定可复现的基线环境，后续所有命令均在此环境执行。

• 操作系统：CentOS Linux 8（x86_64，软件源修复后锁定 vault 快照 8.5.2111）
• JDK：OpenJDK 17.0.1（yum 包 java-17-openjdk-devel，1:17.0.1.0.12-2.el8_5）
• 构建工具：Apache Maven 3.5.4（yum 包 maven，1:3.5.4-5.module_el8.0.0+39+6a9b6e22）
• 组件版本：xml-resolver 1.2（Maven 坐标 xml-resolver:xml-resolver:1.2，84091 字节，字节码 major 45，零传递依赖）
• 验证用工作目录：/root/xresolver-demo（工程）、/root/xresolver-work（DTD/XSD/catalog 素材）

系统与架构确认（实时回显）：

cat /etc/os-release | head -2

NAME="CentOS Linux"
VERSION="8"

uname -m

x86_64

💡 说明：XML Commons Resolver 是库而非服务，安装完成的判定标准是能用一份 catalog 离线解析一个引用外部 DTD 的 XML（4.5 节），而不是某个端口处于监听状态。

二、前置条件与 EOL 源修复

CentOS 8 停维后，官方镜像域名已失效，全新系统上任何 yum 操作都会失败。先复现问题再修复。

官方源现状（实时回显，mirrorlist 域名已无法解析、镜像站返回 404）：

curl -sI --max-time 15 http://mirror.centos.org/centos/8/AppStream/x86_64/os/repodata/repomd.xml | head -2

HTTP/1.1 404 Not Found
Date: Thu, 15 Oct 2026 13:45:47 GMT

yum -q makecache 2>&1 | tail -2

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name ... [Could not resolve host: mirrorlist.centos.org]

修复方案：改用阿里云 centos-vault 归档源。vault 中 CentOS 8 的最后一个快照是 8.5.2111（官方 vault.centos.org 对部分网络返回 403，阿里云同步镜像实测可达），先确认可用（实时回显）：

curl -sI --max-time 15 https://mirrors.aliyun.com/centos-vault/8.5.2111/AppStream/x86_64/os/repodata/repomd.xml | head -1

HTTP/2 200

修改全部 repo 文件：注释 mirrorlist、把 baseurl 指向 centos-vault，并把 $releasever 固定为 8.5.2111（vault 里不存在 8 这个目录，不固定会导致路径 404）：

sed -i -e 's|mirrorlist=|#mirrorlist=|g' \
       -e 's|^#baseurl=http://mirror.centos.org|baseurl=https://mirrors.aliyun.com/centos-vault|g' \
       -e 's|\$releasever|8.5.2111|g' /etc/yum.repos.d/CentOS-*.repo

重建缓存并确认成功：

yum -q makecache 2>&1 | tail -2; echo "EXIT=$?"

EXIT=0

其余前置条件：

1. 具有 root 或 sudo 权限的 CentOS 8 系统。
2. 可访问 mirrors.aliyun.com（源修复）与 Maven 中央仓库 repo1.maven.org（组件下载，实测直连可达）。
3. 至少 2 GB 可用磁盘空间。

三、版本选型说明

XML Commons Resolver 的版本事实以 Maven 中央仓库 maven-metadata.xml 为准：latest/release 均为 1.2，历史版本仅 1.1 与 1.2 两个；新坐标 org.apache.xmlresolver:xmlresolver 在中央仓库不存在（404）。版本谱系、坐标事实与微型库披露详见第 1 篇第三章，结论一致：本文实际采用 1.2。

el8 仓库内可安装的基础组件版本（实时回显）：

yum -q list available java-17-openjdk-devel maven 2>&1 | head -4

Available Packages
java-17-openjdk-devel.x86_64   1:17.0.1.0.12-2.el8_5                   appstream
maven.noarch                   1:3.5.4-5.module_el8.0.0+39+6a9b6e22    appstream

说明：el8 仓库提供 OpenJDK 17（el8_5 起）与 Maven 3.5.4。Maven 3.5.4 较老，但本文 pom 显式固定 maven-compiler-plugin 3.11.0（要求 Maven 3.2.5+），3.5.4 实测可用。

四、方案 A：Maven 依赖安装（在线，推荐）

4.1 方案说明

链路是：yum 安装 JDK 17 与 Maven → 处理 el8 的默认 JDK 回落与 JAVA_HOME 两个坑 → 在 pom.xml 声明 xml-resolver:xml-resolver:1.2 → Maven 自动下载依赖 → 按第 1 篇 4.5 节准备 DTD 与 catalog 素材 → 编译并运行对照验证程序。

4.2 安装 JDK 17 与 Maven

yum install -y java-17-openjdk-devel maven; echo "EXIT=$?"

EXIT=0

安装完成不要急着用——el8 的第一个坑立刻出现：maven 会连带安装 java-1.8.0-openjdk 并把默认 java 指向它（实时回显）：

java -version

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)

用 alternatives 把默认 JDK 切到 17（--list 确认候选，--set 切换 java 与 javac 两项）：

alternatives --list | grep -E '^java |^javac'

java                    auto    /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.312.b07-2.el8_5.x86_64/jre/bin/java
javac                   auto    /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.312.b07-2.el8_5.x86_64/bin/javac

alternatives --set java java-17-openjdk.x86_64 && alternatives --set javac java-17-openjdk.x86_64
java -version | head -1

openjdk version "17.0.1" 2021-10-19 LTS

/usr/lib/jvm 下有三个 17 相关路径，本文统一使用通用软链 java-17-openjdk（实时回显）：

ls -d /usr/lib/jvm/java-17*

/usr/lib/jvm/java-17
/usr/lib/jvm/java-17-openjdk
/usr/lib/jvm/java-17-openjdk-17.0.1.0.12-2.el8_5.x86_64

4.3 el8 必做：显式 JAVA_HOME

el8 的第二个坑：即使 java 已切到 17，Maven 3.5.4 的启动脚本不按 PATH 里的 java 定位 JDK。不带 JAVA_HOME 运行 mvn 仍绑定 1.8（实时回显，与 4.2 节 java -version 输出 17.0.1 形成对照）：

mvn -version | head -3

Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 1.8.0_312, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.312.b07-2.el8_5.x86_64/jre

显式导出 JAVA_HOME 后 Maven 才绑定 17（实时回显）：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
mvn -version | head -3

Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 17.0.1, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-17-openjdk-17.0.1.0.12-2.el8_5.x86_64

为避免每个会话手工 export，写入 profile 持久化并验证登录 shell 生效：

printf 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk\nexport PATH=$JAVA_HOME/bin:$PATH\n' > /etc/profile.d/java17.sh
bash -lc 'echo login-shell JAVA_HOME=$JAVA_HOME'

login-shell JAVA_HOME=/usr/lib/jvm/java-17-openjdk

4.4 创建工程并引入依赖

建立工程目录，pom.xml 与第 1 篇 4.4 节完全一致（依赖 xml-resolver:xml-resolver:1.2、maven.compiler.release=17、maven-compiler-plugin 固定 3.11.0），整段照抄第 1 篇即可；这里给出文件路径与创建命令：

mkdir -p /root/xresolver-demo/src/main/java /root/xresolver-work/dtd /root/xresolver-work/xml /root/xresolver-work/xsd

⚠️ 注意：compiler 插件必须显式固定 3.11.0。Maven 3.5.4 自带的默认插件同样不认识 maven.compiler.release 属性，且在本机 JDK 17 下还会直接触发第九章 Q1 的错误。

验证素材（本地 DTD、XML 实例、catalog.xml）与验证程序 ResolveDemo.java 与第 1 篇 4.5 节完全相同（同名、同路径、同内容），按第 1 篇 4.5 节创建以下文件即可：

• /root/xresolver-work/dtd/config.dtd：本地 DTD
• /root/xresolver-work/xml/config-public.xml：引用不可达域名 dtd.example.invalid 的 XML 实例
• /root/xresolver-work/catalog.xml：OASIS catalog（public/system/uri 三类映射）
• /root/xresolver-demo/src/main/java/ResolveDemo.java：对照验证程序
• catalog 中 <uri name="http://schemas.example.invalid/config.xsd" uri="xsd/config.xsd"/> 条目对应的 /root/xresolver-work/xsd/config.xsd（本篇 4.5 节未用到该条目，XSD 完整场景见第 3 篇；不准备该文件不影响本篇验证）

4.5 编译与运行验证

用默认 JDK（未切换时为 1.8）直接编译，先看失败形态（实时回显，这是 4.2/4.3 节两个坑叠加的必然结果）：

cd /root/xresolver-demo && mvn compile 2>&1 | grep -E 'ERROR.*Fatal|invalid flag'

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project xresolver-demo: Fatal error compiling: invalid flag: --release -> [Help 1]

原因：JDK 8 的 javac 不认识 --release 参数（pom 里 maven.compiler.release=17 生成的编译参数），而 Maven 在无 JAVA_HOME 时绑定了 1.8。按 4.2 节切换 alternatives、按 4.3 节导出 JAVA_HOME 后重新编译：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
cd /root/xresolver-demo && mvn -q compile; echo "EXIT=$?"

EXIT=0

依赖树确认零传递依赖：

mvn -B dependency:tree 2>/dev/null | grep xml-resolver

[INFO] \- xml-resolver:xml-resolver:jar:1.2:compile

跑「带 catalog」与「不带 catalog」对照（素材与第 1 篇一致，本地仓库 jar 路径相同）：

CP=target/classes:/root/.m2/repository/xml-resolver/xml-resolver/1.2/xml-resolver-1.2.jar
java -Dfile.encoding=UTF-8 -cp $CP ResolveDemo catalog

resolveEntity -> file:/root/xresolver-work/dtd/config.dtd
== with catalog: /root/xresolver-work/catalog.xml ==
parse OK, root=config, cost=3 ms

java -Dfile.encoding=UTF-8 -cp $CP ResolveDemo nocatalog 2>&1 | head -4

== without catalog ==
parse FAILED after 145 ms
Exception in thread "main" java.net.UnknownHostException: dtd.example.invalid
        at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:567)

结果解读：与 Ubuntu 实测结论一致——不带 catalog 时解析器对不可达域名发起真实 DNS 解析后抛 UnknownHostException；带 catalog 后外部引用映射为 file:/root/xresolver-work/dtd/config.dtd，3 ms 离线解析成功。xml-resolver 1.2 在 CentOS 8 + JDK 17.0.1 上完整可用。

五、方案 B：jar 直用（离线友好）

面向无 Maven 的场景：从中央仓库下载单个 jar，校验 sha1 后用 javac + java 编译运行，并可用 jar 自带的命令行工具。

5.1 下载与完整性校验

mkdir -p /root/jar-run && cd /root/jar-run
curl -sO --max-time 60 https://repo1.maven.org/maven2/xml-resolver/xml-resolver/1.2/xml-resolver-1.2.jar
curl -sO --max-time 30 https://repo1.maven.org/maven2/xml-resolver/xml-resolver/1.2/xml-resolver-1.2.jar.sha1
ls -l xml-resolver-1.2.jar

-rw-r--r-- 1 root root 84091 Oct 15 14:02 xml-resolver-1.2.jar

echo "期望: $(cut -d' ' -f1 xml-resolver-1.2.jar.sha1)"
echo "实测: $(sha1sum xml-resolver-1.2.jar | awk '{print $1}')"

期望: 3d0f97750b3a03e0971831566067754ba4bfd68c
实测: 3d0f97750b3a03e0971831566067754ba4bfd68c

⚠️ 注意：.sha1 文件内容是「摘要 + 构建路径」，比对取第一列；不一致须重新下载。

5.2 javac 编译与 java 运行

复用第 1 篇 4.5 节的 ResolveDemo.java 与素材：

cd /root/jar-run
cp /root/xresolver-demo/src/main/java/ResolveDemo.java .
javac -encoding UTF-8 -cp xml-resolver-1.2.jar -d out ResolveDemo.java
java -Dfile.encoding=UTF-8 -cp out:xml-resolver-1.2.jar ResolveDemo catalog

resolveEntity -> file:/root/xresolver-work/dtd/config.dtd
== with catalog: /root/xresolver-work/catalog.xml ==
parse OK, root=config, cost=3 ms

5.3 jar 自带命令行工具（可选）

jar 清单中 Main-Class: org.apache.xml.resolver.apps.resolver，java -jar 直接可用：

java -jar xml-resolver-1.2.jar -c /root/xresolver-work/catalog.xml -p '-//Example//DTD Config 1.0//EN' public

Resolve PUBLIC (publicid, systemid):
  public id: -//Example//DTD Config 1.0//EN
Result: file:/root/xresolver-work/dtd/config.dtd

启动时若 classpath 无 CatalogManager.properties 会打印一行 Cannot find CatalogManager.properties，属无害告警，-c 传入的 catalog 正常生效。

六、方案对比与选择建议

选型建议：与第 1 篇结论一致——有构建体系选方案 A；CentOS 8 的特殊性在于方案 A 前置成本更高（源修复 + JDK 切换 + JAVA_HOME），如果目标只是让某个既有脚本具备 catalog 解析能力，方案 B（配合 5.3 节命令行工具）往往更快落地。两者可共存：工程内方案 A 开发，分发侧方案 B。

七、基础配置说明

catalog 文件条目语义（public/system/uri/prefer/nextCatalog）与 CatalogManager.properties 写法与第 1 篇第七章完全一致，不重复展开；本篇强调两点 el8 差异：

1. JAVA_HOME 是硬要求（见 4.3 节实测）：el8 的 Maven 启动脚本不按 PATH 定位 JDK，且 yum 装完默认指向 1.8。持久化配置 /etc/profile.d/java17.sh 后，交互与脚本环境都会带上该变量（bash -lc 验证回显见 4.3 节）。
2. properties 文件路线的键名：xml-resolver 1.2 的 CatalogManager.properties 键名不带 xml.catalog. 前缀（catalogs/verbosity/relative-catalogs/ignore-missing-properties），写成 xml.catalog.files 会被静默忽略回落默认值 ./xcatalog——该坑与操作系统无关，但排查时先查这里。

八、验证清单

九、常见问题（FAQ）

Q1：mvn compile 报 Fatal error compiling: invalid flag: --release？ Maven 绑定了 JDK 8（JDK 8 的 javac 不支持 --release 参数）。两步修复：alternatives --set java java-17-openjdk.x86_64（含 javac）切换系统默认 JDK；export JAVA_HOME=/usr/lib/jvm/java-17-openjdk 让 Maven 绑定 17（el8 上仅切 alternatives 不够，见 4.3 节实测对照）。建议按 4.3 节写入 /etc/profile.d/java17.sh 一劳永逸。

Q2：修复源后 yum makecache 仍报 Cannot prepare internal mirrorlist？ sed 只处理了匹配的文件，确认 /etc/yum.repos.d/ 下所有 CentOS-*.repo 都已改写（grep -l 'mirrorlist=' /etc/yum.repos.d/CentOS-*.repo 应无输出）；另注意 $releasever 必须替换为 8.5.2111，vault 中没有 8 目录。

Q3：mvn -version 显示的 Java 与 java -version 不一致？ 正常现象，见 4.3 节：前者由 JAVA_HOME 决定，后者由 alternatives/PATH 决定。两者都要指到 17 才能编译通过。

Q4：Maven 3.5.4 够用吗？会报插件版本错误吗？ 够用。本文 pom 显式固定 maven-compiler-plugin 3.11.0（要求 Maven 3.2.5+），3.5.4 实测编译通过；若沿用默认绑定的老插件，会因不认识 maven.compiler.release 而按 source/target=1.5 编译并报 Source option 5 is no longer supported。

Q5：中文输出变问号？ 运行时加 -Dfile.encoding=UTF-8（本文所有运行命令已带），或 export LANG=C.UTF-8。

Q6：xml-resolver 1.2 在 el8 的 JDK 17.0.1 上有兼容问题吗？ 没有。该库字节码 major version 45（Java 1.1 基线），本文在 17.0.1 上跑通全部验证；「老字节码 + 新 JDK」正是它跨平台复用的优势。

十、卸载与清理

移除工程、素材与 jar 直用目录：

rm -rf /root/xresolver-demo /root/xresolver-work /root/jar-run

移除 Maven 本地仓库中的 xml-resolver（影响所有工程，慎用）：

rm -rf $HOME/.m2/repository/xml-resolver

移除 JAVA_HOME 持久化配置（仅当不再需要 JDK 17 时）：

rm -f /etc/profile.d/java17.sh

卸载 JDK 与 Maven（仅当不再需要）：

yum remove -y java-17-openjdk-devel java-1.8.0-openjdk maven

十一、参考链接

1. CentOS 8 官方 EOL 说明与归档策略：https://www.centos.org/centos-linux-eol/
2. 阿里云 CentOS vault 归档镜像：https://mirrors.aliyun.com/centos-vault/
3. Apache XML Commons Resolver 组件主页（pom 内官方 URL）：http://xml.apache.org/commons/components/resolver/
4. OASIS XML Catalogs 1.0 规范：https://www.oasis-open.org/committees/entity/spec.html
5. Maven 中央仓库 xml-resolver 坐标页：https://repo1.maven.org/maven2/xml-resolver/xml-resolver/
6. JDK 17 内置 javax.xml.catalog 包文档（对比路线）：https://docs.oracle.com/en/java/javase/17/docs/api/java.xml/javax/xml/catalog/package-summary.html