Question

TL; DR：我尝试创建一个测试，在2个不同的SOAP操作（saveUser，然后是getUser）上执行2个CXF调用，但第二个失败，因为http请求中的SOAPAction已设置as＆＃34; saveUser＆＃34;而不是＆＃34; getUser＆＃34;。我找到了解决这个问题的2个解决方案，但我并不完全满意。

配置

这是我的端点配置：

    final JaxWsProxyFactoryBean jaxWsProxyFactory = new JaxWsProxyFactoryBean();
    jaxWsProxyFactory.setServiceClass(Internal.class);
    jaxWsProxyFactory.setAddress(backendUrl + "INTERNAL");
    jaxWsProxyFactory.setFeatures(getFeatures());
    final Internal portType = (Internal) jaxWsProxyFactory.create();
    ((BindingProvider) portType).getRequestContext().put("thread.local.request.context", "true");
    ((BindingProvider) portType).getRequestContext().put("schema-validation-enabled", "false");

这是我的用法：

internalBackendG5.saveUser(getRequest);
internalBackendG5.getUser(saveRequest);

将两个操作定义为（感谢wsdl2java）：

（我重写一些软件包更简洁，下面的代码可能包含拼写错误）

    @WebMethod(action = "http://www.test.org/internal/saveUser")
@WebResult(name = "saveUserResponse", targetNamespace = "urn:test.com:xsd:internal:userpreferences", partName = "parameters")
public com.test.internal.type.SaveUserResponseType saveUser(
    @WebParam(partName = "parameters", name = "saveUser", targetNamespace = "urn:test.com:xsd:internal:userpreferences")
    com.test.internal.type.SaveUserRequestType parameters
);

和

@WebMethod(action = "http://www.test.org/internal/getUser")
@WebResult(name = "getUserResponse", targetNamespace = "urn:test.com:xsd:internal:userpreferences", partName = "parameters")
public com.test.internal.type.GetUserResponseType getUser(
    @WebParam(partName = "parameters", name = "getUser", targetNamespace = "urn:test.com:xsd:internal:userpreferences")
    com.test.internal.type.GetUserRequestType parameters
);

运行

当我运行测试时，我在第二次调用时收到错误，该错误从后端抛出，作为Soap异常：

javax.xml.ws.soap.SOAPFaultException: Unexpected element {urn:test.com:xsd:internal:userpreferences}getUser found.   Expected {urn:test.com:xsd:internal:userpreferences}saveUser.

当我查看服务器收到的Soap请求时，我得到：

对于第一个请求（saveUser）：

Headers: {[...] SOAPAction=["http://www.test.org/internal/saveUser"], user-agent=[Apache CXF 2.7.12]}
Payload: <soap:Envelope><soap:Body><saveUser>[...]</ns5:saveUser></soap:Body></soap:Envelope>

对于第二个请求（getUser）：

Headers: {[...] SOAPAction=["http://www.test.org/internal/saveUser"], user-agent=[Apache CXF 2.7.12]}
Payload: <soap:Envelope><soap:Body><getUser>[...]</getUser></soap:Body></soap:Envelope>

当我只启动两个请求中的一个时，它们都可以工作。

我找到的解决方案

经过一番研究，我发现Apache Cxf Interceptor SoapPreProtocolOutInterceptor 是负责任的。

当SoapAction字符串已经存在于请求中时，它不会覆盖它。我的第二次调用（由于某些原因，我无法解释）重用在处理第一次调用时计算的Cxf Request上下文！

我做了什么来克服这个问题： - 编写一个在SoapPreProtocolOutInterceptor之前调用的拦截器，强制在标头中删除SoapAction，以强制此拦截器重新计算操作。 - 或者我可以重置2个请求之间的请求上下文：

((BindingProvider) portType).getRequestContext().put(Header.HEADER_LIST, emptyList);

问题

所以我的问题是：是否存在CXF错误？（requestContext不应该在2个请求之间共享）或我错过了一些Cxf配置？ < / p>

PS：我使用了这个依赖项：

group:'org.apache.cxf', name:'cxf-rt-transports-http-jetty', version:'2.7.5'
group: 'org.apache.cxf', name: 'cxf-rt-features-clustering', version:'2.7.12'
group:'org.apache.cxf', name:'cxf-rt-frontend-jaxws', version:'2.7.12'
group: 'org.apache.cxf', name: 'cxf-api', version: '2.7.12'
group: 'org.apache.cxf', name: 'cxf-rt-bindings-soap', version: '2.7.12'

提前致谢！

Answer 1

我有同样的问题，经过一些调试后我觉得我找到了原因。

我在PROTOCOL_HEADERS地图上设置我自己的自定义http标头，然后再调用这样的操作：

Map<String, List<String>> headers = new HashMap<>();
headers.put("header-name", Arrays.asList("value"));
proxy.getRequestContext().put(Message.PROTOCOL_HEADERS, headers);

从您的示例中，我没有看到您正在设置PROTOCOL_HEADERS，但这是我的情况下的根本原因，因为这是包含SOAPAction标头的映射。也许代码的其他部分可能会篡改它。

首先，我们知道客户端代理请求上下文不是线程安全的

http://cxf.apache.org/faq.html


官方JAX-WS答案：不可以。根据JAX-WS规范，客户端代理不是线程安全的。要编写可移植代码，您应该将它们视为非线程安全并同步访问或使用实例池或类似代码。

CXF回答：对于许多用例，CXF代理是线程安全的。例外情况是：

使用（（BindingProvider）代理）.getRequestContext（） - 根据JAX-WS规范，请求上下文是PER INSTANCE。因此，那里设置的任何内容都会影响其他线程上的请求。

这给我带来了一些关于使用这个上下文的危险信号，但它似乎不是问题的原因，我只是添加了一个简单的协议标题，而不是用户特定的。

上下文在ClientImpl类中声明，并用作每个服务调用的基本上下文：

protected Map<String, Object> currentRequestContext = new ConcurrentHashMap<String, Object>(8, 0.75f, 4);

每次请求上下文时，都会执行以下方法：

public Map<String, Object> getRequestContext() {
    if (isThreadLocalRequestContext()) {
        if (!requestContext.containsKey(Thread.currentThread())) {
            requestContext.put(Thread.currentThread(), new EchoContext(currentRequestContext));
        }
        return requestContext.get(Thread.currentThread());
    }
    return currentRequestContext;
}

假设我们没有设置线程局部属性，所以我们总是返回当前的请求上下文，现在我们的PROTOCOL_HEADERS映射中仍然没有SOAPAction头。

然后是SoapPreProtocolOutInterceptor类，（我只提取了setSoapAction（...）方法的相关部分：

        Map<String, List<String>> reqHeaders 
            = CastUtils.cast((Map<?, ?>)message.get(Message.PROTOCOL_HEADERS));
        if (reqHeaders == null) {
            reqHeaders = new TreeMap<String, List<String>>(String.CASE_INSENSITIVE_ORDER);
        }

        if (reqHeaders.size() == 0) {
            message.put(Message.PROTOCOL_HEADERS, reqHeaders);
        }

        if (!reqHeaders.containsKey(SoapBindingConstants.SOAP_ACTION)) {            
            reqHeaders.put(SoapBindingConstants.SOAP_ACTION, Collections.singletonList(action));
        }

在这个客户端执行第一次调用时，我们将在最后一个if语句中结束，从而在 SAME 协议头上设置SOAP_ACTION标头map，它是当前请求上下文的一部分，在ClientImpl类中声明。

此客户端的任何后续请求都将以已填充的映射为基础，在上下文中包含协议头和SOAP_ACTION头，从而导致观察到的行为。我们永远不会输入if语句，为我们的服务调用上下文创建一个带有PROTOCOL_HEADERS的新地图。

<强> SOLUTION：

我认为最干净的解决方案是使用拦截器在协议头图中设置值，请注意我们根本不在基本请求上下文中运行：

public class HttpHeaderExampleInterceptor extends AbstractPhaseInterceptor
{
private static final String HEADER_NAME = "header_name";
private String value;

public HttpHeaderExampleInterceptor(String value)
{
    super(Phase.MARSHAL);
    this.value = value;
}

/**
 * @see org.apache.cxf.binding.soap.interceptor.SoapPreProtocolOutInterceptor#setSoapAction(SoapMessage)
 */
@Override
public void handleMessage(Message message) throws Fault
{
    Map<String, List<String>> protocolHeaders = CastUtils.cast((Map<?, ?>) message.get(Message.PROTOCOL_HEADERS));

    if (protocolHeaders == null)
    {
        protocolHeaders = new TreeMap<String, List<String>>(String.CASE_INSENSITIVE_ORDER);
        message.put(Message.PROTOCOL_HEADERS, protocolHeaders);
    }

    protocolHeaders.put(HEADER_NAME, Collections.singletonList(value));
}
}

希望这有帮助，如果有人在我的调试中发现错误，请分享，因为这个问题确实很有趣。

Answer 2

所以@DDV中的答案是正确的，我只想添加两点：

我在版本3.2.5上遇到了同样的问题，但是PhaseInterceptor进行了一些更改，因此@DDV的答案中的代码无法完全翻译。
我在WS-Addressing中遇到问题，所以我希望这个答案可以帮助人们寻找WS-Addressing

class MessageIdResetInterceptor extends AbstractPhaseInterceptor[SoapMessage](Phase.SETUP_ENDING) {
  override def handleMessage(message: SoapMessage): Unit = {
    val addressing = message
      .getContextualProperty("javax.xml.ws.addressing.context.outbound")
      .asInstanceOf[AddressingProperties]

    addressing.setMessageID(null)
    addressing.setAction(null)
  }
}

在2个请求

配置

运行

我找到的解决方案

问题

2 个答案: