ClassCastException while sending soap request

Question

I am working on a project which already had metro based web-service client implemented. Now, I needed to add another client for different service. I implemented new client, but now it throws exception when there are headers ( Headers are required). If I remove all metro jars, this new client works fine , but obviously my metro client fails. I need guidance on possible options,workarounds or resolutions.

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 few questions with similar problem like here, but they all end up suggesting to remove headers which is not an option for me.

P.S : For the existing webservice client that uses metro jars, we use a connector like client( its a jar that actually includes all metro related classes within itself) provided by the server parties to connect to their server (which I think is very weird). If I move anything from the connector , it voids the support agreement. So I prefer not to remove metro jars, but find alternate way to accommodate with it.

Answer 1

It seems fairly clear that what's happening is there are clashing versions of the metro library in the third party jar, vs the new metro libraries you are trying to use.

My first thought is, do you have any control over the ordering of the classpath? Could you put your own metro jars to either end of the classpath to see if that makes a difference?

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

The other option is to run one or other client in a separate VM, and access through a basic RMI interface. Not ideal I know.

You might also try investigating the Maven shade plugin which supports repackaging of libraries so that they don't clash with other versions, though I'm not sure how well that works with precompiled binaries - in particular the kind of complexity that is involved in JAX-WS packages ...