java - 发送 soap 请求时出现 ClassCastException

Question

我正在开发一个已经实现了基于 metro 的网络服务客户端的项目。现在，我需要为不同的服务添加另一个客户端。我实现了新客户端，但现在它在有 header (需要 header )时抛出异常。如果我删除所有 metro jar，这个新客户端工作正常，但显然我的 metro 客户端失败了。我需要有关可能的选项、解决方法或解决方案的指导。

Caused by: javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.sun.xml.ws.message.saaj.SAAJHeader cannot be cast to com.sun.xml.ws.security.opt.impl.outgoing.SecurityHeader
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:250)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775)
at com.sun.xml.ws.client.Stub.process(Stub.java:429)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:168)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:151)
at com.sun.proxy.$Proxy70.methodName(Unknown Source)
... 15 more

Caused by: java.lang.ClassCastException: com.sun.xml.ws.message.saaj.SAAJHeader cannot be cast to com.sun.xml.ws.security.opt.impl.outgoing.SecurityHeader
    at com.sun.xml.ws.security.opt.impl.JAXBFilterProcessingContext.setJAXWSMessage(JAXBFilterProcessingContext.java:166)
    at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.secureOutboundMessage(SecurityTubeBase.java:381)
    at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:323)
    at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:247)

我发现很少有类似问题的问题，例如 here ，但他们最终都建议删除 header ，这对我来说不是一个选项。

P.S:对于现有的使用 metro jar 的 web 服务客户端，我们使用服务器方提供的连接器，如客户端(它是一个实际上包含所有 metro 相关类的 jar)来连接到他们的服务器(我认为这是很奇怪)。如果我从连接器上移走任何东西，就会使支持协议(protocol)失效。所以我不想移除地铁 jar ，而是找到其他方式来适应它。

Answer 1

很明显，第三方 jar 中的 metro 库与您尝试使用的新 metro 库存在冲突版本。

我的第一个想法是，您是否可以控制类路径的顺序？您能否将自己的 metro jar 放在类路径的两端，看看是否会有所不同？

那么也许最好根据第三方库中包含的地铁库尝试实现您自己的接口(interface)？我不确定这种版本信息是否对您可用，但大多数现代 IDE 应该能够为您反编译第三方 jar 中的类。如果我处于您的情况，这将是我首先尝试的事情，因为它具有“最少移动的部件” 并使用您已经可用的依赖项。

另一种选择是在单独的 VM 中运行一个或另一个客户端，并通过基本 RMI 界面进行访问。我知道这并不理想。

您也可以尝试调查 Maven shade plugin它支持库的重新打包，这样它们就不会与其他版本发生冲突，尽管我不确定它与预编译二进制文件的配合情况如何——特别是 JAX-WS 包中涉及的那种复杂性......