ClassCastException when sending a soap request

Question

I am working on a project in which the metro web service client has already been implemented. Now I needed to add another client for different services. I implemented a new client, but now it throws an exception when there are headers (headers are required). If I delete all the metro banks, this new client will work fine, but obviously my client client is not working. I need guidance on options, workarounds, or solutions.

 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) 

I found several questions with a similar problem, for example here , but all of them ultimately offer to remove the headers that are not suitable for me.

PS: for an existing webservice client that uses metric banks, we use the connector as a client (its bank, which actually includes all metrology-related classes within itself) provided by third-party servers to connect to their server (which I think is very strange) . If I move anything from the connector, it cancels the support agreement. Therefore, I prefer not to remove the metro banks, but to find an alternative way to place with it.

Answer 1

It seems pretty clear that in what is going on, there are conflicting versions of the metro library in a third-party bank, as well as the new metro libraries you are trying to use.

My first thought: do you have any control over the order of the class path? Could you put your own metro banks at any end of the way to class to make sure it matters?

Then, perhaps it would be better to try and implement your own interface in terms of metro libraries included in a third-party library? I'm not sure if this version of the information is available to you, but most modern IDEs should be able to decompile classes in a third-party bank for you. If I were in your situation, this would be the first thing I would try, since it has the "least moving parts" and uses the dependencies that are already available to you.

Another option is to run one or the other client in a separate virtual machine and access through the basic RMI interface. I don’t know what I know.

You can also try expanding the Maven shade plugin , which supports repackaging libraries so that they don’t collide with other versions, although I don’t know how well this works with precompiled binaries - in particular, the complexity associated with JAX packages WS ...