On Wed, Feb 27, 2008 at 6:27 AM, Martin Ritchie <[EMAIL PROTECTED]> wrote:
> On 26/02/2008, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > Hi All, > > [...] > That is at least on the M2.1 branch. I have only had a brief look over > your new parser on trunk which is a way bigger change than the three > lines I suggested to correctly parse wildcard topics in the the > routingkey value if it is in the options. Martin please feel free to review the code and suggest improvements. I ensured that all tests in the DestinationURLTest pass and the other 3 test failures. The remaining test failures were there before the destination changes. (I am working on getting them resolved as well) Perhaps it doesn't require > the / exists between queue and destination. > I wasn't sure about this so currently this is allowed. Fixing this is trivial. > > We need to make this less ambiguous to the end user. > > I propose that we always interpret the following format as QueueName > > direct://amq.direct/mydest?option='1'. > > If the user wants to only specify destination then they must explicitly > use > > the following format. > > topic://amq.topic/myDest/?option='1' > > > > Comments and suggestions are most welcomed. > > Besides can somebody please explain what the destination really means? > and > > also how it used? > > Destination is the name lifted from the Java Client for what is the > routingkey because JMS does not have the concept of routingkey. IMO JMS doesn't really need to worry about the routingkey, exchange etc . at all. The Destination class provides that nice abstraction. So I am not really sure why we need that extra field destination as it currently doesn't map very nicely to any AMQP concept. However I ensured that the current code fucntions exactly the way it used to treat "destination" before. > So what does destination really mean. In the M2.1 code it means the > routingkey and is only used by the Topic and Headers Destinations. > Currently for producers we allow you to use any exchange with any routingKey. For consumers we allow them to bind a queue to any exchange with multiple binding keys. So for 0-10 "destination" doesn't really make much sense. But it is fully supported in the code for backward compatibility. Rajith > > > > -- > > Regards, > > > > Rajith Attapattu > > Red Hat > > blog: http://rajith.2rlabs.com/ > > > > > -- > Martin Ritchie > -- Regards, Rajith Attapattu Red Hat blog: http://rajith.2rlabs.com/
