[ 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)