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. :( >> >> 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
