Description of problem: when the selector contains only spaces the resolving fails Version-Release number of selected component (if applicable): qpid-cpp-0.22-36.el6 How reproducible: 100% Steps to Reproduce: 1. ./qc2_drain --log-msgs dict "q;{create:always, link:{selector:\" \"}}" Actual results: [1] 2014-03-31 14:12:18 [Client] warning Broker closed connection: 501, Illegal selector: '<END>': expected literal or identifier framing-error: Illegal selector: '<END>': expected literal or identifier Expected results: space selector should be equivalent to a empty-string selector Additional info:
It's not clear to me that an empty selector actually is a legal selector. Why do you think it is? If it is legal, what is its effect? And why? I cannot see why selecting all messages is any more logical than selecting no messages (as useless as that would be). In both cases the selector is redundant. It seems to me that it is probably an error somewhere in the application if the selector is empty. It would be fairly simple to implement the empty selector as either true or false if it is required, but is it?
it is legal, and I tried it: ./qc2_spout "q" ./qc2_drain --log-msgs dict "q;{create:always, link:{selector:\"\"}}" {'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 0, 'durable': False, 'ttl': 0, 'properties': {'spout-id': '20775434-7b33-4a7d-af39-695c029fca6c:0', 'x-amqp-0-10.routing-key': 'q'}, 'content': None} thus empty selector is Allowed and it is TRUE I don't also see point to throw and parsing error when the selector contains only whitespace since it is a separator char also implicitly expected by the grammar ... for me it's going against user friendliness to not allow this.
Apologies - I have misunderstood this entire line of discussion. Yes it is incorrect to accept "" and not accept " ". I had assumed that "" was not accepted since the grammar doesn't allow for it (or so I thought!).
A fix for this problem has been committed to the qpid trunk: https://svn.apache.org/r1607739
This was tested on RHEL 6 i686 & x86_64, RHEL 7 x86_64 with following packages: python-qpid-0.34-1 python-qpid-qmf-0.34-1 qpid-cpp-client-0.34-1 qpid-cpp-client-devel-0.34-1 qpid-cpp-debuginfo-0.34-1 qpid-cpp-server-0.34-1 qpid-java-client-0.32-2 qpid-java-common-0.32-2 qpid-java-example-0.32-2 qpid-jms-client-0.2.0-2 qpid-jms-client-docs-0.2.0-2 qpid-jms-client-examples-0.2.0-2 qpid-jms-client-maven-repo-0.2.0-2 qpid-proton-c-0.9-4 qpid-proton-java-0.9.1-2 qpid-proton-java-maven-repo-0.9.1-2 qpid-qmf-0.34-1 qpid-tools-0.34-1 fix works as expected. ->VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-1879.html