On Fri, Oct 3, 2008 at 4:18 AM, Martin Ritchie <[EMAIL PROTECTED]> wrote:
> 2008/10/2 Rajith Attapattu <[EMAIL PROTECTED]>: > > On Thu, Oct 2, 2008 at 6:14 AM, Martin Ritchie <[EMAIL PROTECTED]> > wrote: > > > >> 2008/10/1 Rajith Attapattu <[EMAIL PROTECTED]>: > >> > Hi All, > >> > > >> > Currently we cannot specify arguments for Queue binding and declare, > >> using > >> > the binding URL in the JNDI props file. > >> > > >> > This prohibits the JMS client to leverage some of the options offered > by > >> the > >> > C++ broker. > >> > a) Use the XML exchange as you need to specify the xpath expression as > a > >> > binding argument. > >> > b) Use queue configuration options ( Ex qpid.max_size, qpid.max_count, > >> > qpid.policy_type ...etc) > >> > > >> > Another limitation is that a queue could only be bound to a single > >> exchange > >> > (all though now you could specify multiple binding keys). > >> > > >> > It would be nice if we found a way to express the above using our JNDI > >> prop > >> > file. > >> > One idea is to use the following format. > >> > bind.args.<prop_name>=<prop_value> and > dec.args.<prop_name>=<prop_value> > >> in > >> > the binding URL. > >> > This however doesn't solve the problem of binding to multiple > exchanges. > >> > > >> > Another idea floated by Martin was to separate the queue definition > from > >> its > >> > bindings. > >> > The obvious advantage of this approach is that you could bind your > queue > >> to > >> > multiple exchange/bindingkey pairs. > >> > Ex. > >> destination.<jndiname>=myQueue?durable=true&args.qpid.max_size=100000 > >> > > >> > > >> > binding.<jndiname>=myExchange/myQueue?bindingkey='abc'&args.prop1=prop1value&args.prop2=prop2value > >> > binding.<jndiname>=amq.direct/myQueue?bindingKey='xyz' > >> > > >> > I am sure there are other ideas as well. > >> > Please help by sharing your ideas on a new propsal or how to refine > the > >> > existing mechanism. > >> > (Eitherway we need to ensure backwards compatibility.) > >> > > >> > Regards, > >> > > >> > Rajith Attapattu > >> > Red Hat > >> > http://rajith.2rlabs.com/ > >> > >> Just to refine Rajith's example slightly I think in the binding entry > >> simply having a list of properties makes for easy parsing and makes > >> future expansion/change easier as there is no initial string to be > >> worry about. Do we have a wiki page that details what the args.prop1 > >> args.prop2 might be? I know this is a 0-10 related addition to the > >> URLs but I can't remember or locate that documentation just now: > > > > > > I am not aware of such a page, but I believe the intention is to document > > these properties. > > Jonathan may have already done something on this front. > > If Jonathan has then it would be great if he would contribute it to > the project, I do find it frustrating to hear that there has been > documentation effort performed but not part of this project. :( > I meant documentation for Qpid project. I am not aware of any other documentation that has these properties. (I stand to be corrected though). > > >> > >> destination.myDestination=myQueue?durable=true&args.qpid.max_size=100000 > >> > >> > binding.myDestination=exchange=myExchange&bindingkey='abc'&args.prop1=prop1value&args.prop2=prop2value > >> binding.myDestination=exchange=amq.direct&bindingKey='xyz' > >> > >> Note that the <jndiname> is the same in all three lines. This would > >> allow the client library to automatically perform the binding lookup > >> in JNDI and then perform the AMQP methods, I don't recall what > >> Property files do if you have multiple items with the same key. > >> However if it doesn't give us all the values then the easy solution is > >> to number them, as the XML Configuration would: > >> > >> binding.myDestination.1=... > >> binding.myDestination.2=... > >> > >> While if we might allow access through our qpid.jms extensions to > >> manually bind a destination with a listed JNDI binding I would not > >> start by offering this functionality. > > > > > > IMHO the first and foremost option should be to expose as much > functionality > > through configuration while using 100% pure JMS interfaces. > > My experiance with users is that they are not too happy about using > vendor > > extentions. > > That is fine, means less work adding an extra method to the api to > support but it does mean less flexibility from a clients point of > view. Then again if we don't have a use case from a client to work > with it is a little difficult to formulate an solution to their > problem. > > >> > >> > >> Thoughts > >> > >> Martin > >> > >> -- > >> Martin Ritchie > >> > > > > > > > > -- > > Regards, > > > > Rajith Attapattu > > Red Hat > > http://rajith.2rlabs.com/ > > > > > > -- > Martin Ritchie > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
