Mike, can you submit a JIRA with a very simple test client & WSP that
quickly reproduces the problem? One way of doing this is to download my
minimal DoubleIt Web Service & Client
(http://www.jroller.com/gmazza/entry/web_service_tutorial) which quickly
runs OOTB on Tomcat and make whatever modifications to the client that
reproduce this bug, and then attach it to the JIRA. You will probably
need to add an additional operation ("TripleIt" perhaps) to the WSP's
WSDL to replicate this issue.
Thanks,
Glen
On 01/18/2012 02:04 PM, Mike Hurley wrote:
Here's an update:
* Using a separate client app I confirmed that Op2 on its own will work
with the custom header. Problems come up when it's after another call on the
same proxy object.
* Creating a new proxy object between calls fixes the problem. CXF
seems to be caching stuff between calls when there are extra HTTP headers.
o Creating new proxies makes this work with our tunnel server too (which
needs the custom header).
* CXF 2.5.0 and 2.5.1 behave the same
Before I enter a defect against CXF, I guess I'd like someone to confirm the
way I'm using CXF is correct, make sure it's not user error.
Thanks, Mike
From: Mike Hurley [mailto:[email protected]]
Sent: Wednesday, January 18, 2012 11:19 AM
To: [email protected]
Subject: Adding custom HTTP header to SOAP request causes bad SOAPAction to be
sent
I am trying to consume a SOAP webservice with CXF served by .NET WCF. I used
wsimport to create the Java client objects.
We have a custom http tunnel that routes based on info in an extra http header
field. When trying to use the tunnel I was getting errors from WCF (so I know
the header is added ok). I took the tunnel out of the picture and passed a
dummy ID via a direct connection and there is still the same error. When I
remove the dummy ID from the header everything works as I expect (via the
direct connection).
Here's how I'm creating my proxy object:
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(IMikesService.class);
factory.setAddress("http://example.com/mikesservice";);
IMikesService proxy = (IMikesService)factory.create();
Here's how I'm adding the extra header field:
BindingProvider bp = (BindingProvider)proxy;
Map<String, List<String>> headers = new HashMap<String, List<String>>();
headers.put("MikesCustomHeader", Arrays.asList("myValue"));
bp.getRequestContext().put(Message.PROTOCOL_HEADERS, headers);
(For the following I exclude the namespaces found in the Soap XML payload for
brevity.)
With the extra header, the SOAP action header field doesn't match the SOAP message
payload. For example, the SOAP action may be for Op1 but the SOAP body has
a<Op2/> element. I know this after snooping in with Wireshark. If I don't pass
the extra header, everything lines up ok and the SOAP request works.
It's worth noting that the way this webservice is used that Op1 is called
before Op2 fails on the same proxy object. I have not yet made a test app to
test this tunnel stuff with different SOAP methods on their own. That is one of
my next steps.
Am I missing anything? Is this a known issue?
I found something about needing to use multi value map objects for custom
headers but that supposedly was fixed in the 2.3 or 2.4 series. Plus I know it
was getting through our tunnel since I got WCF SOAP parsing errors back (the
tunnel server does not expose the service on its own, just handles routing).
I'm using CXF 2.5.0 and as I wrote this I saw there's a 2.5.1 out. I didn't see
anything relevant in the release notes, but that's something else I'll try.
Thanks!
Mike Hurley
Software Engineer
[email protected]<mailto:[email protected]>
www.renovosoftware.com<http://www.renovosoftware.com/>
[cid:[email protected]]
--
Glen Mazza
Talend Community Coders
http://coders.talend.com
blog: http://www.jroller.com/gmazza
