---

一句话结论：在 JDK 17 + Spring Boot 3 环境下，Apache CXF 动态客户端无法稳定调用基于 JDK 1.6 / Java EE 的旧版 WebService 服务。最终通过纯原生 HTTP SOAP 客户端彻底解决，业务代码零改动。

---

一、背景与需求

• 运行环境：麒麟 V10 服务器 + OpenJDK 17.0.2 + Spring Boot 3.5.11
• 核心需求：
  1. 项目需要动态调用几十个由 JDK 1.6 / 8 发布的旧版 WebService 服务（WSDL 地址各不相同）
  2. 项目本身也需要作为 WebService 服务端发布接口供其他老系统调用
• 原有实现：基于 Apache CXF 4.x 的 JaxWsDynamicClientFactory 动态客户端
• 异常现象：
  • 本地 IDEA 单元测试正常返回
  • 部署到麒麟服务器后报错：

    Could not compile java files for http://...?wsdl
    "com.frx...impl" 不包含 ObjectFactory.class 或 jaxb.index
    org.glassfish.jaxb.runtime.v2.ContextFactory
    

---

二、四天踩坑全记录

天数	尝试方案	结果	失败原因
Day 1	补充 JAXB 依赖（jakarta.xml.bind-api + jaxb-runtime），排除旧版 jaxb-impl 冲突	❌ 无效	依赖虽正确打包，但 Fat JAR 嵌套结构导致 CXF 运行时仍找不到 JAXB 实现类
Day 2	添加 --add-opens 模块开放参数、requiresUnpack 强制解压 JAXB、-Dloader.path 外部库加载	❌ 无效	仅缓解类可见性，无法解决动态编译所需的完整 javac 环境（JDK 17 已移除 tools.jar）
Day 3	降级 CXF 至 3.5.x（javax 命名空间）；评估降级 JDK 至 8/11	❌ 连锁崩溃	CXF 3.x 与 Spring Boot 3.x 的 Jakarta 生态冲突；降级 JDK 失去安全更新且需整体回退框架
Day 4	切换 CXF 数据绑定为 Aegis / XMLBeans；尝试 Apache Axis2	⚠️ 部分可用但不稳定	学习成本高，且 Axis2 在麒麟系统下仍有未知兼容性隐患

---

三、根本原因：三层不可调和的矛盾

问题本质并非某个配置遗漏，而是 JDK 17 生态与 JDK 6 时代 WebService 技术栈之间出现了三重断裂：

1. 命名空间代沟：服务端 WSDL 基于 javax.* 命名空间（Java EE），CXF 4.x 生成 jakarta.* 代码，两者无法匹配。
2. 动态编译环境缺失：JDK 17 移除 tools.jar，模块化系统封闭了 javax.tools.JavaCompiler 的访问，CXF 无法运行时编译 WSDL。
3. Fat JAR 类加载器隔离：Spring Boot 的嵌套 JAR 结构使 CXF 无法穿透 BOOT-INF/lib 找到 JAXB 实现类。

这三层矛盾叠加，使得任何试图在 JDK 17 上“修复”CXF 动态客户端的努力都注定失败。

---

四、最终解决方案：降级调用方式，而非降级环境

核心思路

既然 CXF 的“智能”变成了负担，那就回归 WebService 的本质——HTTP + XML。用 Java 原生 HttpClient 手动构造 SOAP 信封发送，解析响应时递归处理多层转义，最终输出与 CXF 完全一致的业务 XML 字符串。

架构调整对比

调整前（失败架构）：

业务代码 → CXF 动态客户端 → 运行时编译 WSDL → 动态生成 JAXB 对象 → SOAP 调用
                              ↑
                         此处崩坏

调整后（成功架构）：

业务代码 → NativeSoapClient（纯原生） → 直接构造 SOAP XML → HTTP POST → 解析响应 XML
          ↑                            ↑
    保留原有方法签名             仅用 JDK 自带 HttpClient

关键成果

• ✅ 客户端零 CXF 依赖：移除 cxf-rt-databinding-jaxb、jaxb-xjc、cxf-rt-features-logging 等，JAR 包体积减少 20+ MB
• ✅ 服务端轻量保留：仅用 CXF 发布接口，依赖精简为 cxf-spring-boot-starter-jaxws + jaxb-runtime
• ✅ 无需 --add-opens 参数：启动脚本恢复干净
• ✅ 业务代码零改动：四个原有静态方法签名完全兼容，全局替换类名即可

---

五、核心实现：NativeSoapClientUtils 工具类详解

为了完全替代原有 CXF 动态客户端，我们设计了一个纯原生 SOAP 工具类 NativeSoapClientUtils，其核心设计围绕以下五点展开：

1. 四个兼容静态方法（零业务代码改动）

工具类提供了四个公开静态方法，签名与原有 CXF 调用方法完全一致。业务代码中只需将原类名替换为 NativeSoapClientUtils，其余参数无需任何修改。

// 原 CXF 调用
String result = XxxUtil.getJaxWsDynamicClientFactory(url, method, content);

// 替换为
String result = NativeSoapClientUtils.getJaxWsDynamicClientFactory(url, method, content);

四个方法覆盖了无认证、仅密码认证、带命名空间及用户认证、仅命名空间等所有历史调用场景。

2. 自动命名空间解析（首次访问 WSDL 并缓存）

对于未显式传入命名空间的简化方法，工具类会基于服务端点 URL 自动解析 targetNamespace。解析逻辑仅在首次调用时触发，通过 HTTP GET 获取 WSDL 内容，提取 targetNamespace 属性并存入 ConcurrentHashMap 缓存，后续调用零开销。

private static String getNamespace(String endpointUrl) {
    String pureUrl = endpointUrl.replaceAll("\\?wsdl$", "");
    return NAMESPACE_CACHE.computeIfAbsent(pureUrl, key -> {
        String wsdlContent = fetchWsdl(pureUrl + "?wsdl");
        return parseTargetNamespace(wsdlContent);
    });
}

3. 深度递归反转义（还原纯业务 XML）

老版 WebService 服务端常将业务 XML 作为字符串嵌入 SOAP 响应，并进行了多层 XML 转义（例如 <）。deepUnescape 方法通过循环替换常见转义字符，直到字符串不再变化为止，确保最终输出与 CXF 动态客户端返回的格式完全一致。同时通过 keepXmlHeader 参数控制是否保留 XML 声明头。

private static String deepUnescape(String input, boolean keepXmlHeader) {
    String current = input;
    int maxLoop = 10;
    do {
        current = current.replace("&", "&")
                         .replace("&lt;", "<")
                         .replace("&gt;", ">")
                         .replace("&quot;", "\"")
                         .replace("&apos;", "'");
    } while (current.contains("&lt;") && maxLoop-- > 0);
    if (!keepXmlHeader) {
        current = current.replaceAll("^<\\?xml[^?]*\\?>\\s*", "");
    }
    return current;
}

4. 精准提取响应中的 <return> 节点

不同服务端的响应包装各异：有的直接将业务 XML 放在 <return> 标签内，有的则嵌套在多层元素之下。findReturnNode 方法通过递归遍历 DOM 树，精准定位名为 return 的节点（忽略命名空间前缀），提取其文本内容作为反转义的原始输入。

private static Node findReturnNode(Node node) {
    if ("return".equals(node.getLocalName())) return node;
    NodeList children = node.getChildNodes();
    for (int i = 0; i < children.getLength(); i++) {
        Node found = findReturnNode(children.item(i));
        if (found != null) return found;
    }
    return null;
}

5. 认证支持与客户端缓存

工具类内部维护了一个 HttpClient 实例缓存，以 username:password 为键。当调用带认证参数的方法时，自动获取或创建带 Authenticator 的 HttpClient，避免重复建立连接。对于无认证调用，复用默认客户端。

---

六、最终依赖配置（精简版）

<properties>
    <cxf-rt.version>4.0.7</cxf-rt.version>
    <jaxb.version>4.0.2</jaxb.version>
</properties>

<dependencies>
    <!-- CXF 仅用于服务端发布 -->
    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-spring-boot-starter-jaxws</artifactId>
        <version>${cxf-rt.version}</version>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

    <!-- JAXB API + 运行时（服务端消息序列化） -->
    <dependency>
        <groupId>jakarta.xml.bind</groupId>
        <artifactId>jakarta.xml.bind-api</artifactId>
        <version>${jaxb.version}</version>
    </dependency>
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>${jaxb.version}</version>
    </dependency>

    <!-- 已移除的依赖：jaxb-xjc、cxf-rt-databinding-jaxb、jaxws-rt 等 -->
</dependencies>

---

七、总结

这次历时四天的踩坑最终证明：在 JDK 17 + Spring Boot 3 的技术基线上，强行使用 CXF 动态客户端调用 JDK 6 时代的 WebService 服务，是一条走不通的死胡同。

根本矛盾在于 命名空间、编译环境、类加载机制 的三重断裂，任何试图在框架层面修复的努力都只会陷入更深的泥潭。

最终选择 降级调用方式而非降级环境，用纯原生 HTTP 客户端替代 CXF 动态代理。这一方案：

• 保留了动态多地址调用的灵活性
• 彻底规避了模块化和类加载问题
• 实现了业务代码零改动
• 为项目未来升级 JDK 或 Spring Boot 扫清了障碍

当框架的“智能”变成“负担”，回归协议本质反而是最稳定、最可维护的选择。

👉 点击关注我，更新后第一时间收到推送！

---