This adds preliminary support for SSL connections to a RabbitMQ
server. Instead of providing two clients (QAmqpClient/QAmqpSslClient),
the SSL support was directly rolled into QAmqpClient itself, providing
signals/slots to deal with errors (sslErrors/ignoreSslErrors), and
the ability to assign a QSslConfiguration. Travis testing for ssl
support is currently disabled, pending a solution to a travis
limitation for starting ssl listeners
Since you can provide amqps endpoints, it makes no sense to have a
separate class for SSL client support. This functionality will be
merged directly into QAmqpClient
QAmqpQueue and QAmqpExchange both now have an isDeclared property,
and QAmqpChannel::isOpened was renamed to isOpen to more closely follow
Qt style/api guidelines
RabbitMQ supports publish confirms (Publisher Acknowledgements) on
a given channel. This enables the user to toggle this functionality
and ensure that published messages are in fact published.
- opt for QDataStream overloads instead of read ctor and toStream methods
- removed some unneccesary prefixes to Type and MethodClass enums
- removed documentation from header (this is coming back!)
- cleaned up some confusing code paths, removed unneccessary methods (like readHeader/writeHeader)
This is a very small library, so there is no real pressing need for
a library namespace. Further, the namespacing actually makes it rather
difficult to work with in some cases. Opting for a more "Qt" style
class naming scheme, using the QAmqp class prefix
The internal buffer should not be used blindly when reading
Frame::HEADER_SIZE, as it is error prone and adds nothing over reading
on the stack (and it's only 7 bytes). There are places in this class
where buffer.clear() is called.
amqp_<filename> is used in at least two other C/C++ projects related
to amqp, so this commit changes all our source to use a qamqp header.
This avoids potential clashes, and is more in line with Qt style
QAMQP::Frame used to be public API mostly for MessageProperties. There
is no longer a need to keep this API public, as it should all be wrapped
with the cleaner Message/Queue/Exchange/Client API set
Though it's not necessarily recommended (per spec), Channels can be
shared by multiple Exchanges and Queues. I've added a test here showing
that's possible with QAMQP
We had frame handlers for Close messages from the server, but were not
doing our due diligence and sending a corresponding CloseOk back to the
server after processing. It seems RabbitMQ is generous in this case, but
at least we're doing it the right way now
Fleshed out the previously unimplemented flow control frame handling,
added an auto test for it. Also refactored out the stateChanged ChannelPrivate
method, if we need proper state support in the future it will be added with
a better implementation
existing tests have been immediately declaring queues and exchanges, and
not testing non-delayed declaration (queue/exchange is OPEN when declaration
occurs). these new tests cover this case
There are two distinctive type sets in AMQP, the basic AMQP types
and then the superset of Table value types. This commit attempts to
make that distinction more clear by the addition of a Table class.
Basically, AMQP value type read/write support is left in Frame for the
time being, while table value field read/write support has been moved
to the Table class. Also, a number of type differences exist between
the spec and rabbitmq's binary parser (noted in the errata page) which
were not previously honored.
the message was being needlessly duplicated into the Content frame,
now we only store the size there to be sent out, rather than the whole
message
remove QAMQP prefix in authenticator
Matt Broadstone
Matt Broadstone
Gauthier Brion
Adam Majer