You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2006/09/25 15:31:01 UTC
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps
on the list...]
On Mon, 2006-09-25 at 12:58 +0100, Steven Shaw wrote:
> On 25/09/06, Gordon Sim <gs...@redhat.com> wrote:
> > In general in AMQP the only information used in sending would be the
> > exchange name and the routing key. Perhaps two fields in the headers
> > 'reply exchange' and 'reply routing key' would be better long term
> > approach than trying to encode the information in a single string.
> > Certainly I don't think the queue name (or any of its properties) should
> > be included.
>
> I agree.
+1. Also the format uses nested single-quoted strings. Even if you can
parse it (I have no idea how) it seems very error prone. If we need
nesting then some bracket character is in order, but I think the need
for nesting is evidence of trying to stuff too much into a
Cheers,
Alan.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by Steven Shaw <st...@gmail.com>.
On 25/09/06, Alan Conway <ac...@redhat.com> wrote:
> +1. Also the format uses nested single-quoted strings. Even if you can
> parse it (I have no idea how) it seems very error prone. If we need
> nesting then some bracket character is in order, but I think the need
> for nesting is evidence of trying to stuff too much into a
Alan, I was only agreeing with Gordon about having two fields to
contain the reply-to information where currently some form of encoding
is required. The BindingUrlFormat could be used for this but I think
it makes more sense to simply have the 'reply-to exchange name' and
'reply-to routing-key' as separate fields. This gives just enough
information to do a basic.publish. The exchange-type which is included
in the BindingUrlFormat format is not required.
Note that using the 'getJMSReplyTo' Destination for consuming should
cause an InvalidDestinationException as there is not sufficient
information to consume from this Destination (you could make some
assumptions about the routing-key being a queue name but this could be
wrong - certainly for the topic exchange). I checked the JMS spec and
api documentation. This would seem to be a valid implemementation. It
would certainly be an oddball application design that takes the
reply-to destination and *consumes* from it :).
Steve.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the
list...]
Posted by Martin Ritchie <ma...@jpmorgan.com>.
I agree that the URLs can be viewed as tied to each implementation and is
simply a short cut for creating configuration but why should we limit
ourselves to being unable to share this 'configuration' between clients.
The parsing was very straight forward. Just count the number of tested
quotes. The parsing class gives very accurate output of what is wrong with
the url when parsed. The ConnectionURLTest class demonstrates the parsing
while if you look at URLHelper.parseOptions you can see how I parsed the
url.
The reason for nesting was to allow the same parser to work for the main
amqp url and the broker details that are contained therein.
True there is a lot of 'stuff' to put in the URL but to be able to use the
simplest form of JNDI you need a way of representing the connection factory
as a string. The use of other option makers such as brackets could be used
but I think that would be more confusing as you need to remember when to
use which marker style.
No one had any other suggestions for the Connection URL (other than using
brackets for nested options) so I went ahead with what I thought was best.
The URL parsing works just now but we can come up with another syntax that
captures the required information in a cleaner way.
Cheers
--
Martin Ritchie
Alan Conway
<aconway@redhat.c
om> To
qpid-dev@incubator.apache.org
2006-09-25 14:31 cc
Subject
Please respond to Re: Qpid URL Formats [ was Re: A
qpid-dev@incubato question for the ActiveMQ chaps
r.apache.org on the list...]
On Mon, 2006-09-25 at 12:58 +0100, Steven Shaw wrote:
> On 25/09/06, Gordon Sim <gs...@redhat.com> wrote:
> > In general in AMQP the only information used in sending would be the
> > exchange name and the routing key. Perhaps two fields in the headers
> > 'reply exchange' and 'reply routing key' would be better long term
> > approach than trying to encode the information in a single string.
> > Certainly I don't think the queue name (or any of its properties)
should
> > be included.
>
> I agree.
+1. Also the format uses nested single-quoted strings. Even if you can
parse it (I have no idea how) it seems very error prone. If we need
nesting then some bracket character is in order, but I think the need
for nesting is evidence of trying to stuff too much into a
Cheers,
Alan.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.