Axis 1.4依赖包完全解读：SOAP接口配置与JDK 17兼容避坑指南

简介：这是一份面向Java开发者的Axis1.4 SOAP Web服务依赖包集合，适用于需要维护旧版系统或继续使用Axis1.4开发服务端与客户端的项目，读者最好具备基础Web服务与依赖管理认知。资源内不仅包含Axis核心运行库、JAX-RPC客户端调用库及WSDL处理相关jar包，还特意加入了mail.jar和activation-1.1.jar，用以支持邮件发送接收、MIME类型及复杂附件数据交换等功能，在SOAP消息中传递PDF、Word等非文本内容时尤为有用。此外，配套的log4j.properties可帮助开发者配置日志输出，快速定位运行时异常，规避因依赖缺失或版本冲突引发的部署问题。整个压缩包共12个文件，其中11个为jar库、1个为properties配置文件，大小仅2.57MB，轻量、易集成，适合直接放入类路径或纳入项目依赖管理。已有706人学习下载，对于需要系统梳理Axis1.4依赖关系、补全运行环境或保障老旧服务正常运行的开发者，这份资料能提供清晰的基础支撑。

1. Axis 1.4 依赖包：遗留项目里躲不开的那堆 jar

刚接手一个老系统的人，大概率会在某个角落撞见“axis1.4依赖包”这个词。很多银行接口、政务平台、供应链对接，至今还是 SOAP 协议，服务端跑的是 2006 年就停更的 Apache Axis 1.4。新同事通常的做法是网上下一个 axis1.4 依赖包塞进 WEB-INF/lib，以为万事大吉，结果启动就报 NoClassDefFoundError，跑起来又遇到 NoSuchMethodError，好好的接口一个都调不通。这篇不讲框架理论，只讲落地：依赖包里到底有哪些 jar、新版 JDK 上参数怎么调、客户端服务端怎么配、上线前哪些坑必须提前避开。适合两类人：维护老系统想少踩坑的，以及正在评估新项目要不要引入 Axis 1.4 的。

2. 依赖包构成：axis.jar 之外的五个关键 jar 与最小 Maven 依赖组

2.1 一个 SOAP 请求在 Axis 1.4 里怎么走：依赖包对应的运行时链路

Axis 1.4 不是“一个 jar 全干完”的框架。一个 RPC 调用从发起到最后解析响应，会经过 Call 对象、引擎、传输层、序列化器几个环节，每一段恰恰对应了不同的 jar。缺一个 jar，往往不是启动报错，而是调用到某个具体功能时才炸。

• axis.jar：引擎主体，SOAP 报文构建、解析、序列化框架，以及对外 API 类。
• axis-jaxrpc.jar：JAX-RPC 1.1 的实现，提供 javax.xml.rpc 下的 Service、Call 标准接口实现。
• axis-saaj.jar：SAAJ 1.1 实现，SOAPPart、SOAPBody 这类 SOAP 对象模型归它管。
• wsdl4j：WSDL 文档解析，生成客户端代码、按 WSDL 绑定消息时要用。
• commons-discovery：组件发现机制，Axis 运行时要靠它定位引擎、Provider 等实现类。
• commons-logging：日志门面。

这也能解释为什么很多人只拷 axis.jar 就往 lib 里丢，结果运行时报 ClassNotFoundException。Axis 1.4 写得太早，组件发现用 commons-discovery，日志用 commons-logging，这些都不是 JDK 自带的，必须随依赖包一起走。所以 axis1.4 依赖包的正确理解是一个“最小运行环境”，不是一个 jar 文件。

2.2 最小 Maven 依赖组：一段可以直接抄的 pom.xml

用 Maven 收 Axis 1.4 依赖包是最省心的方式，但不要在 pom 里只写一行 org.apache.axis:axis:1.4。它内部的 POM 声明的传递依赖，不一定覆盖你实际需要的 wsdl4j 和 commons-discovery。我一般显式写全一组：

<!-- Axis 1.4 最小依赖组：核心引擎必选 --> <dependency> <groupId>org.apache.axis</groupId> <artifactId>axis</artifactId> <version>1.4</version> </dependency> <!-- JAX-RPC 实现，客户端服务端都需要 --> <dependency> <groupId>org.apache.axis</groupId> <artifactId>axis-jaxrpc</artifactId> <version>1.4</version> </dependency> <!-- SAAJ 实现，SOAP 报文模型 --> <dependency> <groupId>org.apache.axis</groupId> <artifactId>axis-saaj</artifactId> <version>1.4</version> </dependency> <!-- 注意：这个 wsdl4j 是 Axis 官方重打包过的坐标 --> <dependency> <groupId>org.apache.axis</groupId> <artifactId>axis-wsdl4j</artifactId> <version>1.5.1</version> </dependency> <dependency> <groupId>commons-discovery</groupId> <artifactId>commons-discovery</artifactId> <version>0.5</version> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.2</version> </dependency>

为什么 wsdl4j 要写成 org.apache.axis:axis-wsdl4j 而不是常见的 wsdl4j:wsdl4j？因为 Axis 官方分发包里带的 wsdl4j 是重打包过的，groupId 挂在 org.apache.axis 下。直接引 wsdl4j:wsdl4j:1.6.2 类名对得上，但对某些老式 WSDL 的解析行为不一样，属于“能跑但结果不对劲”的玄学问题，我建议严格跟随发行版附带的版本。

如果运行环境是 JDK 9 以上，这组依赖还不够，还要补 JAXB 和 JAF，第 3 章展开。另外 axis 1.4 本身传递依赖的 commons-discovery 版本偏老，项目里其它组件又可能会带进来一个旧版，最终 classpath 上有两份，这是第 5 章的第一个坑。

2.3 不依赖 Maven 的老项目：手工整理 lib 目录的三个顺序原则

还有相当一部分遗留工程是 Ant 工程，lib 目录堆着几百个 jar。整理 Axis 1.4 依赖包，我一般守三个原则。

第一个原则：按官方 binary 分发目录里的 lib 清单来，不要自己在各个站点下散包。官方分发解开后自带 lib 目录，里面 axis.jar、axis-ant.jar、axis-jaxrpc.jar、axis-saaj.jar、wsdl4j-1.5.1.jar、commons-discovery-0.2.jar、commons-logging-1.0.4.jar 都有。注意分发带的是 commons-discovery 0.2 和 commons-logging 1.0.4，都是远古版本。能升就升到 0.5 和 1.2，但升完一定要跑回归，我遇到过 discovery 查找顺序变化导致找不到 Provider 的情况。

第二个原则：不要把老式 jaxrpc.jar、saaj.jar 直接塞进 WEB-INF/lib。它们把 API 和实现揉在一起，包含 javax.xml.rpc、javax.xml.soap、javax.xml.namespace 这些包，一旦和 JDK 自带实现或容器自带的实现撞车，就会出现签名冲突。这就是 5.2 要讲的经典报错。正确做法是引 axis-jaxrpc 和 axis-saaj 这两个带 groupId 的工件，它们的 manifest 相对干净。

第三个原则：classpath 顺序。手工工程里 axis.jar 放靠前位置，wsdl4j 其次。commons-discovery 和 commons-logging 如果工程里已有别的版本，全局统一，不要两个版本同时在 lib 下。老 Ant 工程没有自动冲突分析，全靠人肉检查：启动加 -verbose:class，grep 关键类确认实际加载路径。

3. 新版 JDK 上把 Axis 1.4 跑起来：三个必调参数与缺失类补齐

3.1 先判断运行环境：JDK 8、11、17 的兼容差异

Axis 1.4 的字节码编译在 JDK 1.3 时代，编译不可能是主要矛盾，主要矛盾在运行期的类加载。JDK 8 及以前，JAXB、JAX-WS、JAF 都直接打进 JDK，Axis 1.4 用得很顺。JDK 9 模块化之后这些内容被移出 JDK，于是同样一份依赖包，JDK 8 上跑得好好的，换到 JDK 11 上首次调用某个类型转换就抛 ClassNotFoundException，指向 javax/xml/bind/DatatypeConverter。

我的经验是：能压在 JDK 8 就压 JDK 8，实在压不了再上 11，上 17 基本等于同时处理反射、依赖冲突、容器兼容三件事。不是不能跑，是性价比低。下面三个参数是 JDK 11 和 17 上的必调项。

3.2 参数一：-Dfile.encoding=UTF-8 先堵住乱码

Axis 1.4 的字符串序列化读取 JVM 的 file.encoding 作为默认字符集。服务器如果是中文 Windows 或故意设了 GBK 的 Linux，SOAP 请求体里的中文会按本地字符集编码，对端服务按 UTF-8 解析，直接乱码。现象是客户端调用不报错，对端收到乱码，日志还看不到异常。

我一般在启动脚本里直接钉死：

JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8"

Tomcat 就放在 setenv.sh 里。参数说明：-Dfile.encoding 控制 JVM 内默认字符集；-Dsun.jnu.encoding 控制文件系统路径等场景的编码，对 Axis 不是必需，但和前者一起设能避免老代码里 File 路径乱码。改完一定要在测试环境验证响应里的中文，不要等上线后对端反馈。

3.3 参数二：补齐 JAXB，解决 DatatypeConverter 找不到

Axis 1.4 的 org.apache.axis.types 包下面有一批 XML Schema 内置类型，比如 Duration、HexBinary、Base64Binary，这些类的内部转换调用 javax.xml.bind.DatatypeConverter。JDK 9 以后这个类不在 JDK 里，只要 WSDL 里有 xsd:duration、xsd:hexBinary 之类的类型，一调用就 NoClassDefFoundError。

Maven 工程里补这段：

<!-- JDK 9+ 必补：Axis 1.4 的 types 包依赖它 --> <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-runtime</artifactId> <version>2.3.1</version> </dependency> <!-- JDK 11+ 缺 JAF，activation 类会找不到 --> <dependency> <groupId>javax.activation</groupId> <artifactId>activation</artifactId> <version>1.1.1</version> </dependency>

jaxb-api 提供 javax.xml.bind.DatatypeConverter，jaxb-runtime 是底层实现，activation 是 JDK 11 上 JAF 缺失时的补充。版本注意：2.3.1 是走 javax.* 命名空间的最后一代，再往上就是 jakarta.* 了。Axis 1.4 这种老代码不认识 jakarta，别顺手引成 jakarta.xml.bind，否则又是一轮 NoClassDefFoundError。

3.4 参数三：--add-opens，解决 JDK 17 的反射访问异常

JDK 17 默认强封装 JDK 内部 API，Axis 1.4 的组件发现和序列化代码里用了反射访问 JDK 内部类。报错一般是 InaccessibleObjectException 或 IllegalAccessError，堆栈指向某个 java.base 包。按日志提示来开，我一般遇到什么开什么：

--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED

参数说明：java.lang 和 java.util 是序列化最常碰到的两个包，ALL-UNNAMED 表示对所有非模块化代码开放。如果启动日志明确报了别的包，按报错追加即可。JDK 8 不需要无脑加，加了只是放宽模块封装，没有实际收益。这里有个排查习惯：JDK 17 上报错不要第一时间加参数，先看堆栈里 Axis 的类是被谁加载的，用 -verbose:class 确认依赖包有没有被容器污染，这往往比试各种 add-opens 快得多。

4. 写一个能上线的 SOAP 客户端：WSDL2Java 生成与手写 Call 两条路

4.1 用 WSDL2Java 生成桩代码：一条命令和它的输出产物

拿到第三方接口的 WSDL 以后，最快的是用 Axis 自带工具生成全套客户端代码。命令要跑在完整依赖包的 classpath 上，别只放 axis.jar：

java -cp axis.jar:axis-jaxrpc.jar:axis-saaj.jar:wsdl4j-1.5.1.jar:commons-discovery-0.5.jar:commons-logging-1.2.jar \ org.apache.axis.wsdl.WSDL2Java \ -o ./src \ -p com.example.thirdparty \ http://example.com/service/hello?wsdl

参数说明：-o 指定输出目录，-p 指定生成 Java 包的包名前缀。命令跑完后 src 目录下会多出几类文件：一个接口定义，一个 *ServiceLocator，一个 *SoapBindingStub，还有若干自定义类型 Bean。Locator 是定位服务的工厂，Stub 是对端 WebService 的客户端代理，接口声明了 WSDL 里暴露的方法。

生成完先看一眼输出里有没有“skipping unknown type”的警告，有就回到 WSDL 确认类型定义。生成的 Bean 类也最好不要手改，序列化逻辑依赖类名和属性结构，改了之后响应解析对不上。

4.2 用生成的 stub 调接口：覆盖 endpoint 和设置超时

生成的 Locator 默认 endpoint 取自 WSDL 里的 soap:address location。实际联调经常要指到测试环境或网关地址，我一般会显式覆盖：

// 用测试环境地址覆盖 WSDL 里的 endpoint HelloWorldServiceLocator locator = new HelloWorldServiceLocator(); locator.setHelloWorldServiceEndpointAddress( new java.net.URL("http://192.168.25.10:8080/ws/HelloWorld")); HelloWorldServiceSoapBindingStub stub = (HelloWorldServiceSoapBindingStub) locator.getHelloWorldService(); // 超时单位是毫秒，按对端处理耗时设置 stub.setTimeout(15000); String result = stub.sayHello("world");

setTimeout 的单位是毫秒，15 秒是一个常见的初始值。它设置的是底层 Socket 超时，而不是应用层超时，如果对端服务本身处理时间就长，设到 30 秒以上。这里有一个隐蔽问题：生成的 Locator 类在构造时可能解析 WSDL，当前环境访问不了 WSDL 地址的话，构造 Locator 会非常慢，甚至卡住。这种场景下，覆盖 endpoint 也救不了初始化，只能走 4.3 的手写方式。

4.3 没 WSDL 或者不想生成代码：手写 Call 是最小可运行方案

对接老系统时，对方常常只给接口文档，没有 WSDL。此时用 Call 对象手拼请求是最直接的路：

import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.namespace.QName; import javax.xml.rpc.ParameterMode; Service service = new Service(); Call call = (Call) service.createCall(); // endpoint 指向实际网关地址 call.setTargetEndpointAddress( new java.net.URL("http://gateway.example.com/ws/hello")); // QName 第一个参数是 namespaceURI，不要和方法名搞混 call.setOperationName(new QName("http://service.example.com/", "sayHello")); call.setSOAPActionURI("urn:sayHello"); // 声明入参类型和模式：IN 表示入参 call.addParameter("arg0", XMLType.XSD_STRING, ParameterMode.IN); call.setReturnType(XMLType.XSD_STRING); call.setTimeout(15000); String result = (String) call.invoke(new Object[] { "world" });

几个经常写错的地方：setOperationName 的 QName 第一个参数是 namespaceURI，不是方法名，第二个参数才是方法名。namespaceURI 错一个字符，SOAPAction 对不上，对端直接返回 fault。addParameter 第三个参数是参数模式，IN 表示入参，OUT 表示出参，写漏了行为不稳定。setReturnType 不能省，省略后调用返回的是 SOAP 元素节点对象，直接强转 String 会 ClassCastException。invoke 的入参数组顺序保持和 addParameter 声明顺序一致。

4.4 服务端发布：web.xml + AxisServlet + deploy.wsdd

自建 WebService 服务端时，Axis 1.4 的套路是把框架当 Servlet 塞进容器。web.xml 关键配置：

<servlet> <servlet-name>AxisServlet</servlet-name> <servlet-class>org.apache.axis.transport.http.AxisServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping>

服务实现类就是一个普通 Java 类，然后用 deploy.wsdd 声明暴露哪些方法：

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="HelloWorld" provider="java:RPC"> <parameter name="className" value="com.example.HelloWorld"/> <parameter name="allowedMethods" value="sayHello"/> </service> </deployment>

把 deploy.wsdd 放到 classpath 下，用 AdminClient 推送：

java -cp axis.jar:axis-ant.jar:axis-jaxrpc.jar:axis-saaj.jar:commons-discovery-0.5.jar \ org.apache.axis.client.AdminClient deploy.wsdd

参数说明：provider="java:RPC" 表示走 RPC 风格绑定；allowedMethods 是白名单，只暴露 sayHello 这个方法。不写 allowedMethods 的话，Axis 会把类的所有 public 方法都暴露出去，这是上线前必须检查的安全隐患。部署完成后，服务 WSDL 地址是 http://host:port/应用名/services/HelloWorld?wsdl。

还有一种 JWS 方式：把实现类改成 HelloWorld.jws 直接扔到 /services 目录，AxisServlet 自动编译并发布。适合临时接口验证，线上不要用，类加载不可控，也没法配 allowedMethods。

5. Axis 1.4 依赖包避坑指南：5 个上线前后最容易踩的坑

5.1 坑一：编译期正常，运行期 NoSuchMethodError

现象：项目能编译，Tomcat 启动正常，一调 WebService 接口，抛 java.lang.NoSuchMethodError，堆栈指向 commons-discovery 或 Axis 的某个方法。

原因：classpath 上存在多个版本的 commons-discovery 或 commons-logging。编译时 Maven 用的是较高版本，运行期部署的 war 里却带了旧版；或者同一个 war 里两个版本的 jar 并存。Axis 1.4 运行期用 commons-discovery 查找引擎实现，查到的类和编译期不是同一个版本，签名对不上就抛 NoSuchMethodError。

解决：先执行mvn dependency:tree | grep commons-discovery定位哪些 artifact 传递进来。在 pom 里把非 Axis 方向传进来的旧版本排除，或用 dependencyManagement 把版本锁到 0.5。部署前再检查一次 war 包 lib 目录，确保只有一个 commons-discovery、一个 commons-logging。

5.2 坑二：javax/xml/namespace/QName 的 SecurityException

现象：部署到 Tomcat 8.5/9 上，启动阶段或首次请求时抛 java.lang.SecurityException，提示 class "javax.xml.namespace.QName"'s signer information does not match signer information of other classes in the same package。

原因：WEB-INF/lib 里旧版 jaxrpc.jar 或 saaj.jar 的 javax 命名空间类带旧签名信息，而容器或 JDK 自带的 JAX-WS API 里同类不同签名，两个来源的类混在同一个包，JVM 安全管理器校验到混用就拒绝。

解决：把 Axis 分发包里的 jaxrpc.jar、saaj.jar 替换成 axis-jaxrpc、axis-saaj 这些规范打的 jar，并清掉 WEB-INF/lib 里 javax.xml.namespace、javax.xml.soap 包下的类，让容器父类加载器统一提供这些 API。如果必须保留旧 jar，至少去掉签名信息再重新打包：

mkdir qname-fix && cd qname-fix jar xf jaxrpc.jar javax/xml/namespace find . -name '*.SF' -delete find . -name '*.DSA' -delete jar cf jaxrpc-fixed.jar javax/

这个场景我见得最多，属于“一看报错就知道 lib 里有老 jar”的典型。加签名清理命令不是为了推广改包，是给实在没法换 jar 的老工程一个补救手段。

5.3 坑三：生成的 stub 返回 null，没有任何异常

现象：服务端日志每次都有请求，响应也正常，客户端拿到的返回值却是 null，没有异常、没有 fault。

原因：Axis 1.4 的 WSDL2Java 对 document/literal wrapped 风格支持不好，对 xsd:anyType 或未命名返回元素的解析尤其弱。生成的代码不知道怎么解析响应体，序列化器把响应体当空处理。

解决：先确认 WSDL 的 style。rpc/encoded 一般不出现这个问题；document/literal 要检查返回元素是否定义了明确 type。最省事的是不依赖生成代码，改用手写 Call，setReturnType 设成明确类型。如果接口里有 anyType，就设成 XMLType.XSD_ANYTYPE，拿到元素节点后自己解析。

5.4 坑四：Tomcat reload 应用后，内存只增不减

现象：开发环境用 Tomcat manager 热部署了几十次，老年代或元空间持续增长，最后 OOM。

原因：Axis 1.4 运行期有大量静态缓存，commons-discovery 的 DiscoverSingleton 会持有 WebappClassLoader 的引用。应用 reload 后，老 ClassLoader 无法被回收，连带轴相关 jar 和业务类全部留在堆里。

解决：本地调试关掉 autoDeploy，每次重启容器；线上不要用 reload，发布走独立实例重启。如果确实需要热部署，可以加 ServletContextListener 在 contextDestroyed 时调用 AxisServlet 的 destroy 做清理，但只能缓解，不能根治。老框架在容器化时代就这个命，别硬扛。

5.5 坑五：Axis 1.4 和容器自带的 JAX-WS 实现打架

现象：把应用部署到 JBoss/WildFly 等自带 JAX-WS 的中间件时，AxisServlet 报 java.lang.NoSuchMethodError，比如 javax.xml.soap.SOAPPart.getContentId()。

原因：容器优先加载了自己的 saaj/jaxws 模块，WEB-INF/lib 里 axis-saaj 的类没被应用类加载器加载，两个实现版本不一致，方法签名对不上。

解决：在 war 包的 META-INF 下放 jboss-deployment-structure.xml，显式排除容器的 saaj 模块：

<jboss-deployment-structure> <deployment> <exclusions> <module name="javax.xml.soap.api" /> </exclusions> </deployment> </jboss-deployment-structure>

排除后，应用类加载器才会从 WEB-INF/lib 里加载 axis-saaj。如果容器里模块名不一样，用管理控制台查实际模块名再说。这类中间件我最后基本都换 Tomcat 或 Jetty 独立部署，少一道兼容问题。

6. 把 axis 1.4 依赖包隔离到独立 lib：一个能和 JDK 17 共存的兜底方案

当整体升级无望、又必须跑在新 JDK 上时，我用的兜底方案是把 Axis 1.4 依赖包关进一个独立的 URLClassLoader，不让它污染应用其它部分。做法是自定义一个类加载器，指定目录下的 axis 相关 jar 才由它加载，其它类一律委托父加载器：

public class AxisIsolatedLoader extends URLClassLoader { public AxisIsolatedLoader(URL[] urls, ClassLoader parent) { super(urls, parent); } @Override protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { if (name.startsWith("java.") || name.startsWith("javax.")) { // java/javax 统一走父加载器，避免包签名冲突 return super.loadClass(name, resolve); } synchronized (getClassLoadingLock(name)) { Class<?> c = findLoadedClass(name); if (c == null) { try { c = findClass(name); } catch (ClassNotFoundException e) { // axis 目录里没有，再走父加载器 c = super.loadClass(name, resolve); } } if (resolve) { resolveClass(c); } return c; } } }

使用方式：把 axis.jar、axis-jaxrpc.jar、axis-saaj.jar 等统一放进一个 lib/axis 目录，用这个加载器加载，然后通过反射构造 Axis 的 Service 和 Call 对象。应用业务代码不直接依赖 Axis 类，只依赖一个封装接口。隔离的好处是 javax.xml 命名空间由父加载器统一提供，签名冲突消失；Axis 自身那套老类的加载边界也被圈住，不会和容器其它模块互相覆盖。

验证方法值得单独说：启动时加-verbose:class，或打印 AxisIsolatedLoader 的 URL 列表，确认 axis.jar 是由隔离加载器加载的，而不是 WebAppClassLoader；再调用一次接口，确认线程上下文 ClassLoader 在调用期间被切到隔离加载器，调用结束还原。

这个方案我只推荐给“没有升级预算”的遗留系统使用，前提是后续维护的人能接得住。它不改变 Axis 1.4 的老行为，只把问题圈在可控范围里。回头想，每次遇到新 JDK 报错，最该做的不是急着堆参数，而是先搞清类是被谁加载的。用 -verbose:class 兜一圈，比盲目试各种 --add-opens 快得多。这个习惯帮我省了不少事，希望帮到你。

本文还有配套的精品资源，点击获取