Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim <g...@redhat.com> wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the configuration of
destinations and expanding the capabilities in this regard. However
I wonder
if perhaps a simpler syntax is possible?
Even the simplest example:
xqueue.myQueue = name='myQueue'
xdestination.myQueue = queue=myQueue
Could you compare with new proposal I sent to the list and see if the
simplest format is good enough?
In the new one it would be as simple as
destinationx.<jndi-name> = myQueue
So are the following entirely independent and equivalent forms for the
same thing?
queuex.my-jndi-name = {name=MyQueue, durable=true}
destinationx.my-jndi-queue = MyQueue; {durable=true}
If so, whats the motivation for the first form?
I think the queuex stuff is only to control whether and how you
auto-declare queues, so the common case would be:
destinationx.my-jndi-name = MyQueue
And then if you wanted to auto-declare the queue you would add this:
queuex.MyQueue = {auto-create=true, durable=true, ...}
I see. That is not at all obvious (at least to me) from either the
syntax or the proposal text.
Is the auto-create not implied in that case? I.e. why else would you
have a queuex type declaration other than to auto-create the queue?
Would such a queue be auto-created for either the first consumer or the
first producer to be created?
As I understand it you would only add options to the destination in
order to configure the individual producers and consumers created from
the destination, e.g.:
destinationx.my-jndi-name = MyQueue; {prefetch=100, sync=true, ...}
The advantage as I viewed it was more related to intuitiveness (since
the file is a properties file).
I think most destination definitions will be quite simple and may not
be as confusing with the more compact format.
I don't think the compact syntax is confusing; I think its just
another syntax embedded in the properties file syntax. I could
certainly live with that, but it's probably worth thinking about it
and being sure that the reasons for it are clear.
I think the source of confusion may be around the various options,
what they mean, how they are interpreted or whether they are valid in
a given context or not.
I think the main reason for using this format rather than a flat
properties file format is that we also need a syntax for something
people can pass to Session.createTopic("...") and
Session.createQueue("..."), and the properties file format doesn't work
so well for that.
Thats a fair point (at least to an extent!).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
