You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current getSubscribersFor method can find all subscribers for a given channel and topic. However, it will only look for exact matches to a topic binding (so if you subscribed with "some.topic.#", but you call getSubscribersFor and pass "some.topic.goodness", then the subscription you created with the wildcard binding will NOT be returned in the results.
I'm proposing we change this so that the topic you pass to getSubscribersFor gets compared to the subscription definition topic bindings via the bindingsResolver.
@ifandelse I agree with leveraging the bindingsResolver. Any extension to postal should be, I think, internally consistent with the design of postal itself. This is particularly important to me since I use a custom bindingsResolver suggested to me in this forum to handle RESTful style topics instead of AMQP-style topics.
I think I would lose out if the bindingsResolver weren't leveraged (I had overlooked the impact of wildcard matching on the unsubscribeAllFor scenario).
@ifandelse I just downloaded rc3. I'll be playing with the bits this weekend. I don't believe I'm using getSubscribersFor, so I think I'll be fine there.
The current
getSubscribersFor
method can find all subscribers for a given channel and topic. However, it will only look for exact matches to a topic binding (so if you subscribed with "some.topic.#", but you callgetSubscribersFor
and pass "some.topic.goodness", then the subscription you created with the wildcard binding will NOT be returned in the results.I'm proposing we change this so that the topic you pass to getSubscribersFor gets compared to the subscription definition topic bindings via the bindingsResolver.
What say you @dcneiner @arobson @nicholascloud @estaylorco?
The text was updated successfully, but these errors were encountered: