[
https://issues.apache.org/jira/browse/CAMEL-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Mindenhall updated CAMEL-8400:
-----------------------------------
Description:
I'm beginning to work with MQTT brokers, and have found that having an endpoint
only able to subscribe to a single topic is limiting. Looking at the code, the
underlying implementation (fusesource mqtt-client) accepts an array of Topics
when creating a subscription. I have modified the camel-mqtt component to
allow for a "subscribeTopicNames" option, which expects a comma-delimited list
of topics that will be subscribed.
I'm attaching a patch (after creating the issue) that includes additional unit
tests for this functionality. It would be really great if this could be
accepted before the 2.14.2 release is cut!
A couple of notes:
# If the new "subscribeTopicNames" option is specified, anything specified for
the existing "subscribeTopicName" option will be ignored. Long term, it
doesn't make sense to maintain both options. Should the singular version be
deprecated? If so, I can submit another patch that deprecates that option
within the code.
# I don't know how to submit a "patch" for the component documentation. Here's
something that would work:
||Property||Default||Description||
|subscribeTopicName| |The name of the Topic to subscribe to for messages.
_Deprecated since 2.14.2 (use subscribeTopicNames instead)._|
|subscribeTopicNames| |*Since Camel 2.14.2.* A comma-delimited list of Topics
to subscribe to for messages. \\ \\ Note that each item of this list can
contain MQTT wildcards ('\+' and/or '#'), in order to subscribe to topics
matching a certain pattern within a hierarchy. For example, '\+' is a wildcard
for all topics at a level within the hierarchy, so if a broker has topics
"topics/one" and "topics/two", then "topics/\+" can be used to subscribe to
both. A caveat to consider here is that if the broker adds "topics/three", the
route would also begin to receive messages from that topic.|
was:
I'm beginning to work with MQTT brokers, and have found that having an endpoint
only able to subscribe to a single topic is limiting. Looking at the code, the
underlying implementation (fusesource mqtt-client) expects an array of Topics
when creating a subscription. I have modified the camel-mqtt component to
allow for a "subscribeTopicNames" option, which expects a comma-delimited list
of topics that will be subscribed.
I'm attaching a patch (after creating the issue) that includes additional unit
tests for this functionality. It would be really great if this could be
accepted before the 2.14.2 release is cut!
A couple of notes:
# If the new "subscribeTopicNames" option is specified, anything specified for
the existing "subscribeTopicName" option will be ignored. Long term, it
doesn't make sense to maintain both options. Should the singular version be
deprecated? If so, I can submit another patch that deprecates that option
within the code.
# I don't know how to submit a "patch" for the component documentation. Here's
something that would work:
||Property||Default||Description||
|subscribeTopicName| |The name of the Topic to subscribe to for messages.
_Deprecated since 2.14.2 (use subscribeTopicNames instead)._|
|subscribeTopicNames| |*Since Camel 2.14.2.* A comma-delimited list of Topics
to subscribe to for messages. \\ \\ Note that each item of this list can
contain MQTT wildcards ('\+' and/or '#'), in order to subscribe to topics
matching a certain pattern within a hierarchy. For example, '\+' is a wildcard
for all topics at a level within the hierarchy, so if a broker has topics
"topics/one" and "topics/two", then "topics/\+" can be used to subscribe to
both. A caveat to consider here is that if the broker adds "topics/three", the
route would also begin to receive messages from that topic.|
> camel-mqtt: multiple topic subscriptions
> ----------------------------------------
>
> Key: CAMEL-8400
> URL: https://issues.apache.org/jira/browse/CAMEL-8400
> Project: Camel
> Issue Type: Improvement
> Components: camel-mqtt
> Affects Versions: 2.14.2, 2.15.0
> Reporter: Mark Mindenhall
> Priority: Minor
> Attachments:
> 0001-CAMEL-8400-camel-mqtt-support-for-multiple-topic-sub.patch
>
>
> I'm beginning to work with MQTT brokers, and have found that having an
> endpoint only able to subscribe to a single topic is limiting. Looking at
> the code, the underlying implementation (fusesource mqtt-client) accepts an
> array of Topics when creating a subscription. I have modified the camel-mqtt
> component to allow for a "subscribeTopicNames" option, which expects a
> comma-delimited list of topics that will be subscribed.
> I'm attaching a patch (after creating the issue) that includes additional
> unit tests for this functionality. It would be really great if this could be
> accepted before the 2.14.2 release is cut!
> A couple of notes:
> # If the new "subscribeTopicNames" option is specified, anything specified
> for the existing "subscribeTopicName" option will be ignored. Long term, it
> doesn't make sense to maintain both options. Should the singular version be
> deprecated? If so, I can submit another patch that deprecates that option
> within the code.
> # I don't know how to submit a "patch" for the component documentation.
> Here's something that would work:
> ||Property||Default||Description||
> |subscribeTopicName| |The name of the Topic to subscribe to for messages.
> _Deprecated since 2.14.2 (use subscribeTopicNames instead)._|
> |subscribeTopicNames| |*Since Camel 2.14.2.* A comma-delimited list of
> Topics to subscribe to for messages. \\ \\ Note that each item of this list
> can contain MQTT wildcards ('\+' and/or '#'), in order to subscribe to topics
> matching a certain pattern within a hierarchy. For example, '\+' is a
> wildcard for all topics at a level within the hierarchy, so if a broker has
> topics "topics/one" and "topics/two", then "topics/\+" can be used to
> subscribe to both. A caveat to consider here is that if the broker adds
> "topics/three", the route would also begin to receive messages from that
> topic.|
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
