Martin Ritchie wrote:
Hello all,
I've just recently be going over the fact that we automatically
declare and bind queues when we create a new consumer. In a real world
system we wouldn't want to have client code automatically
creating/binding JMS Queues. In fact the broker should prevent this ..
but RBAC/ACLs already have a JIRA and I have a more pressing need to
prevent the client side creations.
Though the first (non-passive) declare will create a queue, in general
declare doesn't always imply create (and the passive flag can prevent
creation). The aim of the declare is to assert that a queue exists. How
valuable that actually is depends on the use I suspect. It does seem
worth declaring a queue before sending (setting the passive flag where
we don't want it to be created on the fly, but want to rely on it being
statically configured). As an attempt to consume from a non-existent
queue results in the same error as passively declaring that queue, it
seems like there is less value there.
I have augmented my local code to stop the active creation and
bindings by default and setting system property:
org.apache.qpid.client.declareJMSQueueWithConsumer = true
will restore the previous behaviour.
I just wondered if any of my fellow qpid-ians would have a problem
with this change in the java client until we re-layer and remove this
auto-creation code for queues completely.
I quite like the ability to dynamically configure the queues needed for
an application. I do agree that you want tight control over that as it
may not be appropriate in many deployments.
