Description of problem: Using the following command the binding amq.direct [key] => q is created: # java -cp $CLASSPATH org.apache.qpid.example.Drain "q; {assert:always, node: {x-bindings: [{exchange: 'amq.direct', key:'key'}]}}" No object shall be created when only assert action is used in address string. Error message indicating assertion failure shall be displayed, command shall end with non-zero return code. Moreover the assertion using java client behaves another way than using other clients. Please see additional info. Version-Release number of selected component (if applicable): qpid-java-0.10-6 How reproducible: 100% Steps to Reproduce: 1. qpid-config add queue q 2. java -cp $CLASSPATH org.apache.qpid.example.Drain "q; {assert:always, node: {x-bindings: [{exchange: 'amq.direct', key:'key'}]}}" 3. return code is equal to 0 4. list queue q bindings 4. there is a new binding amq.direct [key] => q Actual results: The binding is created when assert is used in address string. Expected results: No object shall be created when only assert action is used in address string. Error message indicating that the assertion failed is displayed, command ends with non-zero return code. The assertion results behaves the same way as using other clients. Additional info: Assertion general rules at present time: At present the assertion only checks for capabilities requested that differ from the defaults: i.e. * If you have requested a durable queue, it will fail if the actual queue is non-durable. The reverse test isn't currently applied; i.e. you cannot at present assert that the queue is non-durable only that it is durable. consider following example: # qpid-config add queue q --durable # java -cp $CLASSPATH org.apache.qpid.example.Drain "q;{assert:always, node:{durable:False}}" Exception in thread "main" javax.jms.JMSException: Error registering consumer: org.apache.qpid.AMQException: The name 'q' supplied in the address doesn't resolve to an exchange or a queue The fact that the Java client may assert that a queue is non-durable is not necessarily wrong, but it is in conflict with the definition above and with the other clients behaviour. All the clients shall behave the same way. C++ client behaviour: # qpid-config add queue q1 # $cppapi/drain "q1;{assert:always, node:{durable:False}}"; echo $? 0 # $cppapi/drain "q1;{assert:always, node:{durable:True}}"; echo $? Queue not durable: q1 1 # qpid-config add queue q2 --durable # $cppapi/drain "q2;{assert:always, node:{durable:False}}"; echo $? 0 # $cppapi/drain "q2;{assert:always, node:{durable:True}}"; echo $? 0