On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim <g...@redhat.com> wrote:
> On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
>>
>> Hi All,
>>
>> Currently quite a bit of options can be configured via the Java
>> Connection URL, which tends to make it ungainly and quite error prone.
>> If we are to think in terms of a "Connection String" instead of a
>> "Connection URL" , then I believe we could come up with a more simpler
>> solution.
>>
>> Therefore I'd like to make the following proposals.
>>
>> 1) Introduce a simple scheme for a "Connection String" ( inspired by
>> the new addressing format)
>> 2) Also allow the ability to specify the config using a property file.
>>
>> * I hate having to specify user/pass when the auth mech (ex kerberos)
>> is not even using it. Therefore it should be optional !
>>
>> 1. 0 Connection String
>> ---------------------------
>> 1.1 Examples
>> "tcp://localhost"
>> "tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
>> ssl-trust-store : ~/cert.jks ..} "
>> "tcp://host1.example.com; {user: bob, pass: nuts} ,
>> tcp://host2.example.com; {user: ding, pass: dong} ..."
>>
>> 1.2 Syntax
>> <broker> [ ;<options> ] [ ,<broker> [ ;<options> ]] *
>>
>> Where broker is::
>> <protocol>:// [ host [ ":" port ] ] (protocol = {tcp|vm|rdma}
>
> The c++ client currently supports the AMQP 0-10 definition of a url syntax.
> Do we want to support that more widely? It would be good to improve
> consistency across clients a little.
Well my motivation behind the thread was to get this out in the open.
IMO I think we as a project *must* have the same connection url/string
syntax across all clients.
I thought I'd start with the Java side and then take it from there.
The connection "URL" has been used for two reasons.
1) To identify which broker(s) to connect to
2) As a configuration mechanism.
My issue is if we treat the whole thing as a "URL" then supporting the
latter makes the whole thing ugly and error prone.
The Java connection url is a case in point.
I would rather treat it as a connection string which consists of two
**distinct** parts.
a) A broker (identified by a URL - ex tcp://localhost:5672/vhost )
b) A bunch of key:value pairs associated with the broker url.
Based on past experience, munging them together to form a URL is a
good recipe for disaster.
> The approach for specifying SSL is also different across the different
> clients.
Which is a pity I think.
>
>> Where options is::
>>
>> {<key> :<value>, ... }
>>
>> And values may be:
>> - numbers
>> - single, double, or non quoted strings
>> - maps (dictionaries)
>> - lists
>>
>>
>> 2.0 Config file
>> -----------------
>> Example
>>
>> JNDI prop file
>> connection.my-connection = "tcp://localhost; {id : 1}"
>> connection.my-con = "tcp://host1.example.com; {id: 2} ,
>> tcp://host2.example.com; {id: 2}, tcp://host3.example.com; {id: 3}"
>
> I'm not hugely keen on the split file approach or on the id as a way to
> reference externally defined options. What is the motivation for that?
Sometimes the connection string gets quite crowded especially if you
have a few props to specify.
I was just exploring the possibility of pushing that part to a config file.
Another advantage of the given format is that it makes it easy to see
the diffs btw different versions of the config file, something that is
quite impossible with the current approach.
Through experience I have seen that most companies version control the
deployment descriptors/config files etc., so that any given time they
could rollback to a previous deployment.
Rather than talk things in the abstract I decided to express my
questions/ideas via a proposal.
Therefore I was more keen on getting it out quickly with some
examples, than coming up with a solid proposal.
I hope the latter objective could be achieved through a discussion
that starts of from some basic idea.
>> =========Connection.properties=========
>> con id : 1 {
>> ssl: true
>> sasl-mech : EXTERNAL
>> ssl-trust-store : ~/cert.jks
>> ssl-key-store : ~/keys.jks
>> ssl-verify-hostname : true
>> }
>>
>> con id : 1 {
>> sasl-mech : GSSAPI
>> sasl-hostname : host1.example.com
>> sasl-protocol : qpidd
>> sasl-encryption : true
>> tcp-nodelay : true
>> }
>>
>>
>> con id : 3 {
>> user : ding
>> pass : dong
>> tcp-nodelay : true
>> }
>>
>> ==================================
>>
>> Connection.properties can be loaded from the classpath or specified as
>> an option in the connection string.
>> (You could also trivially have a connection property file per connection).
>>
>> Comments and suggestions are most welcomed !
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
