Effective October 27, 2012, online and email support for FuseSource products will move to Red Hat support channels. For more information, please see the JIRA Migration to Red Hat FAQ. As of October 27th, please open all new issues in the Red Hat Customer Portal .
The solution for returning SOAP header described here: http://cxf.apache.org/faq.html (Question: How can I add soap headers to the request/response?). However it does not work with SOAP faults.
I'm using binding server (so not @WebServiceProvider but @WebService). Please see attached test case for more details. I believe it's due to below code snippet of JAXWSMethodInvoker.java class:
try {
if ((params == null || params.isEmpty()) && m.getDeclaringClass().equals(Provider.class)) {
params = Collections.singletonList(null);
}
res = CastUtils.cast((List)super.invoke(exchange, serviceObject, m, params));
addHandlerProperties(ctx, handlerScopedStuff);
//update the webservice response context
updateWebServiceContext(exchange, ctx);
} finally {
//clear the WebServiceContextImpl's ThreadLocal variable
WebServiceContextImpl.clear();
}
As SOAP headers are copied within the function updateWebServiceContext() but it is only called in success scenario and all stuff is cleared in finally block so in case of a fault, the headers are lost.
Description
The solution for returning SOAP header described here: http://cxf.apache.org/faq.html (Question: How can I add soap headers to the request/response?). However it does not work with SOAP faults.
I'm using binding server (so not @WebServiceProvider but @WebService). Please see attached test case for more details. I believe it's due to below code snippet of JAXWSMethodInvoker.java class:
try {
if ((params == null || params.isEmpty()) && m.getDeclaringClass().equals(Provider.class)) {
params = Collections.singletonList(null);
}
res = CastUtils.cast((List)super.invoke(exchange, serviceObject, m, params));
addHandlerProperties(ctx, handlerScopedStuff);
//update the webservice response context
updateWebServiceContext(exchange, ctx);
} finally {
//clear the WebServiceContextImpl's ThreadLocal variable
WebServiceContextImpl.clear();
}
As SOAP headers are copied within the function updateWebServiceContext() but it is only called in success scenario and all stuff is cleared in finally block so in case of a fault, the headers are lost.
Here is attached test case.
Start.java under "cxf-soapfault-headers/cxf-server" directory is a server mainline.
ServiceTests.java under "cxf-soapfault-headers/cxf-binding-client" directory is a JUnit test case.
So just load both modules to eclipse and set break point on JAXWSMethodInvoker class of server side to see how it behaves in an exception scenario.
It is a bit similar as SF-283 but the main difference is that in this case, I am using @WebService while in JIRA SF-283 @WebServiceProvider was used.
Joe Luo added a comment - 22/Jan/11 12:34 AM Here is attached test case.
Start.java under "cxf-soapfault-headers/cxf-server" directory is a server mainline.
ServiceTests.java under "cxf-soapfault-headers/cxf-binding-client" directory is a JUnit test case.
So just load both modules to eclipse and set break point on JAXWSMethodInvoker class of server side to see how it behaves in an exception scenario.
It is a bit similar as SF-283 but the main difference is that in this case, I am using @WebService while in JIRA SF-283 @WebServiceProvider was used.
Improvement
Resolved
Major
Returning SOAP headers doesn't work with Faults
Start.java under "cxf-soapfault-headers/cxf-server" directory is a server mainline.
ServiceTests.java under "cxf-soapfault-headers/cxf-binding-client" directory is a JUnit test case.
So just load both modules to eclipse and set break point on JAXWSMethodInvoker class of server side to see how it behaves in an exception scenario.
It is a bit similar as
SF-283but the main difference is that in this case, I am using @WebService while in JIRASF-283@WebServiceProvider was used.