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, ...}
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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
