After the discussions with Martin and Robert here is what I think. The BindingURL was used for 3 things in the code. 1) The broker used it (apparently not anymore - which is good) 2) ReplyTo - still the 0-8 clients use this and needs to support it. 3) JNDI
I propose we revamp the BindingURL to support the following use cases. So we can have some flexibility while still using 100% pure JMS. 1) First and foremost we need to maintain backward compatibility to maintain the 0-8 stuff. 2) Allow an AMQQueue to use a routing key different from the queue name. 3) Allow an AMQQueue to bind to a Fannout exchange. 4) Allow to bind to a queue with more than one routing key. The change I made have broken use case 1 slightly. I need to fix that. Option 2 and 3 can be done with the current changes. Option 4 needs to be thought through as it has some implications on a producer etc. One suggestion is to have a list of rotingkeys. Ex. direct://amq.direct/queueName?routingKey="rk1 del rk2 del rk3 .." We need to find a suitable delimiter for this. For the issue with producers, when we define a destination for the producer we can put only one. Or if a list is there we can take the first one. Comments are critisisms are equally welcomed. Rajith On Jan 17, 2008 4:05 AM, Martin Ritchie <[EMAIL PROTECTED]> wrote: > Rajith , > > The BindingURL was writing (as it is java) from the JMS point of view. > Hence destination is where you are publishing to in JMS. Now the > reason the wiki does not match the code is because of a problem I > realised after implementing the original spec. The URL cannot have a > '#' in the middle as this will prevent the URI class from correctly > parsing it. Hence the need to have the routing_key as an option. > > I would also be very cautious about changing this format as it is used > in a lot more places that the Java. I would suggest that if you do > wish to change the format then changing the code so that it matches > the wiki documentation would be the way to go. If you do that then a > change will be needed to update the C++ and .NET as they both use this > format to encode the replyTo field. > > Really what should happen is that the BindingURL be used solely on the > broker for parsing the bindings defined in the configuration file and > either a simplified version or a new format be decided for replyTo > encoding. We used to use Q|T+RoutingKey but that limited us in the > java to only using the built in exchanges. Perhaps a subclass of > BindingURL could be used to only present the values required to > perform a reply. > > > On 16/01/2008, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > folks, > > > > I see two minor issues with the AMQBindingURL and AMQDestination > > The binding URL is defined as follows. > > > <exch_class>://<exch_name>/[<destination>]/[<queue>]?<option>='<value>'[,<option>='<value>']* > > RoutingKey is given as a valid option (See BindingURL class). > > > > Then in AMQDestination we see that the constructors has a field called > > "destinationName" (in addition to exchangeName). > > > > As per the AMQP spec, destination refers to the exchange you are > publishing. > > Therefore the binding url format is incorrect, as destination has no > meaning > > there. > > It cannot be the routing_key as it is given as a valid option. So I > propose > > we get rid of it. > > However the documentation here is correct, but sadly not reflected in > the > > code properly. > > http://cwiki.apache.org/qpid/bindingurlformat.html > > > > Also in AMQDestination, destinationName is used as the routingKey which > is > > creating confusion and it is also semantically wrong. > > The field destinationName should refer to the exchange we are > publishing. > > But we already have a field named "exchangeName". > > So I renamed the field destination to routingKey and modified the code > > accordingly in both AMQQueue and AMQTopic. > > > > -- > > Regards, > > > > Rajith Attapattu > > Red Hat > > blog: http://rajith.2rlabs.com/ > > > > > -- > Martin Ritchie > -- Regards, Rajith Attapattu Red Hat blog: http://rajith.2rlabs.com/
