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.

Xeniaxeno

What about implementing a custom SoapHandler/Interceptor, where you might be able to marshall/unmarshall the headers yourself? – Dak

Look into the 'Headers' methods like getHeaders()... – Dak

docs.oracle.com/cd/E13222_01/wls/docs103/webserv_adv/… – Dak

I do have a SoapHandler. This is where I add my headers. I print my soap message after adding headers, and they are properly created with headers. However, It fails after that . I will definitely look int getHeaders() and see if I can find something interesting there. thank you for your input. – Xeniaxeno

No, problem. Hope it helps. – Dak

seeing the ClassCastException makes me think you're dealing with a dependency problem, whereas both clients bring in different version or expect different versions of SAAJHeader, seems like Metro might be bringing in something that wasn't what the second client was compiled with. – Borlase

What error do you get when you remove the metro jars? – Princedom

Jimmy, did you find a solution? – Decker

As said in the question, it was jar conflict. I ended up creating proxy services isolating all metro related implementation. – Xeniaxeno

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 ...

Franglais

I do have control over the classpath ordering and have already tested putting it in last of order, but there was no difference. Running in separate VM is not ideal. implement your own interface in terms of the metro libraries is possible option, but have to see how feasible is it. I do have versions info. Thanks for your input – Xeniaxeno