非受控Tomcat7环境部署CXF代理应用遇Metro类转换异常求解决

你遇到的是JAX-WS SPI实现类加载优先级冲突，核心逻辑如下：

• JAX-WS 2.x规范要求通过ServiceLoader查找javax.xml.ws.spi.Provider的实现类，查找流程会遵循类加载器的委托逻辑，只要上层类加载器（对应Tomcat的Common类加载器，也就是tomcat/lib目录）先找到Metro对应的Provider实现，就会优先使用Metro生成SEIStub代理，而非CXF的ClientProxy代理，最终触发类转换异常。
• 你在测试服修改应用级Context.xml的delegate属性不生效，大概率是测试服Tomcat在全局配置（如conf/web.xml、conf/catalina.properties）中设置了全局类加载规则，覆盖了单个Web应用的自定义配置。

以下方案按无测试服权限的优先级排序，可根据实际情况选择：

1. 手动强制指定CXF的JAX-WS Provider（无需修改服务器配置，可靠性最高） #

直接绕过ServiceLoader的自动查找逻辑，从根源上避免加载到Metro的实现：

• 在所有JAX-WS API调用之前，添加代码指定CXF的Provider实现：

  // 适配你当前Tomcat7+CXF3.3.8的老版JAX-WS前缀
  System.setProperty("javax.xml.ws.spi.Provider", "org.apache.cxf.jaxws.spi.ProviderImpl");
  

  注：如果后续升级JAX-WS依赖到jakarta前缀的版本，需要把属性名改为jakarta.xml.ws.spi.Provider。
• 更稳妥的方式是完全绕过JAX-WS的Service类初始化逻辑，直接使用CXF自带的客户端工厂创建代理，示例代码：

  JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
  factory.setAddress("你的目标SOAP服务地址");
  // 直接绑定服务接口，不会触发JAX-WS SPI查找逻辑
  YourServiceInterface client = factory.create(YourServiceInterface.class);
  

2. Web应用内置SPI配置（无需改代码，适用于类加载规则未强制委托父加载器的场景） #

如果不想修改业务代码，可以在Web应用的WEB-INF/classes/META-INF/services/目录下手动创建SPI声明文件，强制Web应用类加载器优先加载CXF的实现：

• 新建文件名为javax.xml.ws.spi.Provider，文件内容仅写一行：

  org.apache.cxf.jaxws.spi.ProviderImpl
  

• 该文件会被Web应用的Webapp类加载器优先扫描，只要类加载逻辑允许应用先加载自身路径下的资源，就不会优先读取上层tomcat/lib下的Metro SPI配置。

3. 本地对齐测试服类加载规则验证 #

你已经可以通过在本地Tomcat的lib目录放置相同的Metro jaxws-xxx包复现问题，建议在本地环境拉取测试服的全局配置（如catalina.properties、全局web.xml），模拟测试服的类加载规则，验证上述方案有效性后再部署，避免上线后出现失效问题。

4. 临时获得服务器权限后的根治方案 #

如果后续可以临时修改测试服配置，可直接将tomcat/lib下的3个Metro jaxws-xxx包移出类加载路径，或是在catalina.properties的tomcat.util.scan.DefaultJarScanner.jarsToSkip配置中添加这几个包的名称，从根源上消除类加载冲突。

内容的提问来源于stack exchange，提问作者WordCrafter