Wildfly的JAXWS实现似乎忽略了bindingProvider属性com.sun.xml.ws.transport.https.client.SSLSocketFactory

Question

我的环境是作为应用程序服务器的Maven项目和Wildfly（8.2.1）。我需要使用SOAP将传入的REST调用与第三方服务器连接。我需要SSL客户端身份验证；因此，我有自己的KeyStore和TrustStore。因此，我创建了自己的SSLContext，需要让WebService使用此SSLContext。

Wildfly出现问题，并且使用了JAXWS的实现（Apache CXF？）-我在这里描述了它（但是还有另一种方法可以解决该问题；因此，它不是重复的帖子！）：
Wildfly：如何使用JAXWS-RI而不是Apache CXF（仅WebService客户端）

主要问题之一似乎是Wildfly中使用的JAXWS似乎忽略了使用property设置自己的SSLContext com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory：

MyWS_Service service = new MyWS_Service(null, new QName("http://...", "MyWS"));
MyWS port = service.getMyWSSOAP();

BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://hostname:443/.../...");

// the following setting is ignored!
bindingProvider.getRequestContext().put("com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

// in some posts, we see that we need to eliminate 'internal' in the property. This does not help!
bindingProvider.getRequestContext().put("com.sun.xml.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

可以忽略的证据是，如果我HttpsURLConnection.setDefaultSSLSocketFactory(mySslSocketFactory)用来设置SSLContext，它确实可以工作-意味着SSL连接的建立要归功于导入到SSLContext中自定义的TrustStore设置的根CA。

如果我们查看其他文章（例如，如何以编程方式设置JAX-WS客户端的SSLContext？），则该属性应该有效（即使对于Wildfly，根据那里的一些评论）。但这不是我的情况。这可能是什么原因？

Answer 1

问题是Apache CXF忽略了

bindingProvider.getRequestContext().put(
    "com.sun.xml.[internal.]ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

在某些地方有些评论相反。

因此，我的最终解决方案是以编程方式设置HTTPConduit使用的（而不是在cxf.xml文件中设置配置）。

// Set custom SSLContext.
HTTPConduit conduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setSSLSocketFactory(customSSLContext.getSocketFactory());
conduit.setTlsClientParameters(tlsClientParameters);

我希望这可以帮助遇到类似问题的人…