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                                                   
             <[EMAIL PROTECTED]                                             
             om>                                                        To 
                                       [email protected]       
             2006-09-25 14:31                                           cc 
                                                                           
                                                                   Subject 
             Please respond to         Re: Qpid URL Formats [ was Re: A    
             [EMAIL PROTECTED]         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 <[EMAIL PROTECTED]> 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.
 

Reply via email to