[
https://issues.apache.org/jira/browse/CXF-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-3463.
--------------------------------------
Resolution: Not A Problem
See workaround in the comments.
> Allow programmatic injection of TLSClientParameters, before an HTTPConduit is
> created.
> --------------------------------------------------------------------------------------
>
> Key: CXF-3463
> URL: https://issues.apache.org/jira/browse/CXF-3463
> Project: CXF
> Issue Type: New Feature
> Components: Configuration, Core
> Affects Versions: 2.3.4
> Environment: Embedded jetty and CXF installation, but without using
> Spring configuration. Connecting to an HTTPS SOAP service.
> Reporter: Peter Schwarz
> Priority: Major
>
> With programmatic configuration:
> Allow for the creation and injection of a default set of TLSClientParameters
> to be set, which will be used by all HTTPConduits. This could be
> accomplished, for example, through a call to
> {{BusFactory.getDefaultBus().setExtension(myDefaultTlsClientParamters,
> TLSClientParameters.class);}}
> Reason:
> When trying to connect to a SOAP service over HTTPS, the HTTPConduit created
> only uses the default TLSClientParameters. This causes a connection failure
> (evidenced by a WSDL parsing exception), if there are any specific
> requirements needed to make the SSL connection (for example, specific cipher
> suites).
> This can be worked around by implementing both ConduitInitiatorManager and
> ConduitInitiator wrappers, which can set the TLSClientParamters as needed
> before the HTTPConduit is returned for usage. However, this is a bit
> unwieldy, as well as creates set of classes whose reasons for existence may
> be unclear to developers not familiar with their creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
