[
https://issues.apache.org/jira/browse/CXF-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13548619#comment-13548619
]
Yaroslav Gnatyuk commented on CXF-4741:
---------------------------------------
Yes, that's what I did to fix it in my code
{code}
client.getBus().setProperty(
AbstractConduitSelector.CONDUIT_COMPARE_FULL_URL, true );
http.getTarget().getAddress().setValue( endpointUrl );
{code}
But I can't understand the logic in findCompatibleConduit(). Let's say I'm
using same client but send data to different endpoints. I have
https://endpoint1.com and https://endpoint2.com and each one has it's own TLS
config. However if AbstractConduitSelector.CONDUIT_COMPARE_FULL_URL is not set
or set to false, and I already configured it for endpoint1 my conduit might be
reused for endpoint2 because both have same https scheme.
That's why I set AbstractConduitSelector.CONDUIT_COMPARE_FULL_URL to true in my
code so that whole address gets compared
> Different conduits are used when configuring stub and sending actual message
> ----------------------------------------------------------------------------
>
> Key: CXF-4741
> URL: https://issues.apache.org/jira/browse/CXF-4741
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.6.2, 2.6.4
> Reporter: Yaroslav Gnatyuk
>
> I was trying to set TLS context as described here: [How to configure the
> HTTPConduit for the SOAP
> Client?|http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-HowtoconfiguretheHTTPConduitfortheSOAPClient%3F]
> However it doesn't work in CXF 2.6.2 and 2.6.4 while it worked perfectly fine
> in 2.5.3
> When looking into the code (line numbers are for version 2.6.4) I discovered
> that during this configuration a new message is created and passed to conduit
> selector (in this case UpfrontConduitSelector) - ClientImpl.getConduit():846.
> New conduit is created, assigned to message and returned.
> However when I do an actual call, I get to ClientImpl.doInvoke():486 where
> another message is created. Later on prepare() is called on conduit selector
> at ClientImpl.prepareConduitSelector():850 but the message is different so
> another conduit is created.
> This results in my conduit config being disregarded and I'm getting
> SSLHandshakeException
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
