The transport connection setting was broken in r1156262.
Consider the following test code:
Using Qpid 0.12 client libraries, the above code would use SSL. But with Qpid 0.14, the code will not use SSL.
The change in behaviour is a result of code changes to the ConnectionImpl::tryConnect function in cpp/src/qpid/client/amqp0_10/ConnectionImpl.cpp in r1156262
Prior to that revision, the SimpleUrlParser was used, and settings passed to a Connection::open overload directly. This worked fine.
Post that revision, the code looks like this:
(I added the QPID_LOG calls).
The QPID_LOG calls produce output like:
The problem is that the Url constructor is defaulting the protocol to TCP (via UrlParser::protocolAddr). Then, when the Connection::open overload is called, the Url object's defaulted-but-now-explicit protocol value (TCP) is used in preference to the settings.protocol value (SSL).
I think the correct solution here, thought it would be non-trivial, would be to pass settings (or at least settings.protocol) to the Url constructor as an optional default protocol. Then the Url class should use that default protocol instead of TCP when the address string does not include an explicit protocol.
Another option would be to provide some sort of Url::protocolWasDefaulted flag so that the ConnectionImpl::tryConnect function could override from settings when appropriate - this would be less code change, but the above solution would be more elegant IMO.
Note, the obvious workaround is to always use explicit protocols in URLs. That is, always use "ssl:hostname" instead of "hostname".
|Field||Original Value||New Value|
|Assignee||Gordon Sim [ gsim ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Fix Version/s||0.15 [ 12319043 ]|
|Resolution||Fixed [ 1 ]|
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|17d 5h 25m||1||Gordon Sim||01/Mar/12 06:40|
|515d 12h 13m||1||Justin Ross||29/Jul/13 18:53|