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

Reply via email to