[ 
https://issues.apache.org/jira/browse/CXF-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13548580#comment-13548580
 ] 

Yaroslav Gnatyuk commented on CXF-4741:
---------------------------------------

I think I found it, when debugging 
AbstractConduitSelector.findCompatibleConduit() I discovered that address 
comparison is done incorrectly. If full comparison is switched off (which is 
the default case) it does the following:

{code}
            if (!full) {
                int idx = conduitAddress.indexOf(':');
                conduitAddress = idx == -1 ? "" : conduitAddress.substring(0, 
idx);
                idx = actualAddress.indexOf(':');
                actualAddress = idx == -1 ? "" : actualAddress.substring(0, 
idx);
            }
            
            if (conduitAddress.equalsIgnoreCase(actualAddress)) {
                return c2;
            }
{code}

So effectively only address protocols are compared. I guess the intention was 
quite the opposite that is to compare addresses without protocols. Can you 
confirm please?
                
> 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

Reply via email to