You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2010/03/12 00:41:28 UTC
Client configuration & Connection URL
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}
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}"
=========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-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 19, 2010 at 11:08 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/19/2010 02:57 PM, Alan Conway wrote:
>>
>> URLs are a widely accepted format for addressing and part of the AMQP
>> 0-10 standard for addressing brokers, so I think it would be valuable
>> to make it easy for these strings to be included in URLs.
>
> Does the currently defined URL scheme for AMQP 0-10 support options? It is
> certainly a different form from the example URls given in this thread and
> currently is only supported in c++.
I don't know if it does as it was designed for a specific purpose.
IIRC correctly the AMQP 0-10 format was introduced to provide the list
of brokers through the failover exchange.
All most all the options are client side configuration and don't need
to be shipped around.
We could use existing URL parsers if we somehow shoehorn the
connection string into a URL format.
But I'd argue the issues surrounding the current Java URL connection
format far outweighed those benefits.
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Gordon Sim <gs...@redhat.com>.
On 03/19/2010 02:57 PM, Alan Conway wrote:
> URLs are a widely accepted format for addressing and part of the AMQP
> 0-10 standard for addressing brokers, so I think it would be valuable
> to make it easy for these strings to be included in URLs.
Does the currently defined URL scheme for AMQP 0-10 support options? It
is certainly a different form from the example URls given in this thread
and currently is only supported in c++.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Alan Conway <ac...@redhat.com>.
On 03/19/2010 07:42 AM, Rafael Schloming wrote:
> Alan Conway wrote:
>> On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
>>> On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway<ac...@redhat.com> wrote:
>>>> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>>>>
>>>>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> On 03/11/2010 06: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} ..."
>>>>>>>
>>>>>>
>>>>>> I think there is value in keeping to a URL-friendly
>>>>>
>>>>> Could you please elaborate on this?
>>>>
>>>> I mean avoiding characters that are not allowed in URLs, in particular
>>>> spaces which are troublesome in a variety of contexts. However I if the
>>>> spaces are optional (I think they are given that there are always other
>>>> separators involved ,:{} then that may not be an issue.
>>>
>>> Alan I think we should treat the "Broker" portion of it as a URL and
>>> the key : value pairs separately.
>>> IMO opinion they are two distinct entities that should be treated
>>> separately.
>>>
>>
>> 1. You need a URL parser to parse the broker part, migth as well use
>> it for the whole thing.
>>
>> 2. You're going to want to pass these strings around by various means
>> outside of qpid (filesystem, program arguments, web pages, other XML
>> docs...) URL strings are well known and easy to pass around. Strings
>> with custom syntax and embedded spaces will pose a variety of problems
>> - you'll end up having to use some form of quoting, URL syntax
>> provides this for you.
>>
>> I'll go one step further and suggest that we should use the standard
>> query-string syntax for name/value pairs:
>>
>> tcp://localhost:8672/?ssl=true&sasl-mech=EXTERNAL&ssl-trust-store=~/cert.jks
>> ...
>>
>> Every URL parser out there already knows how to parse this.
>>
>> I'll go another step further and propose that we modify the new
>> address string format to be URL friendly.
>> I see 2 issues: spaces and ';'
>>
>> I think spaces is a non issue as you can just leave them out - am I
>> correct on that?
>>
>> The issue with ';' is that URLs use it as a separator (alternative to
>> '&') in the query string. I suggest we simply drop it. Then we can
>> easily embed addresses in URLS, e.g.
>>
>> tcp://localhost:8672/?ssl=true;sasl-mech=EXTERNAL;address=myqueue{create:always,node-properties:{durable:true}}
>> ...
>
> I don't think we can really remove the ';'. The name/subject part of the
> address can include fairly complex patterns that include curly braces,
> so we really need something to separate the options from the address,
> and ';' is pretty much the only reasonable option for this given the
> syntax for what goes on either side.
>
> The address syntax was specifically chosen because the URL syntax is
> insufficiently powerful to be able to reasonably express everything that
> needs to be able to go into an address, things like nested maps/lists,
> embedded selector strings, etc. The address syntax is pretty much a pure
> subset of python dictionary syntax, so it's always going to be more
> expressive than what will be able to naturally fit in a URL.
>
> Personally I think if we nest it's more natural to do it the other way
> around. Nest the more limited syntax inside the more powerful one. This
> is trivial: {url: "foo://bar.baz.qux"}. You're always going to have
> problems if you try to nest the other way around.
>
You can nest any string in a URL by using the standard URL quoting. It's nicer
though, if you don't have to quote.
URLs are a widely accepted format for addressing and part of the AMQP 0-10
standard for addressing brokers, so I think it would be valuable to make it
easy for these strings to be included in URLs. I don't think there's a big
change needed, or that python dictionary syntax is something that we need to
stick to for a multi-language system like qpid.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Rafael Schloming <ra...@redhat.com>.
Alan Conway wrote:
> On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
>> On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway<ac...@redhat.com> wrote:
>>> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>>>
>>>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@redhat.com>
>>>> wrote:
>>>>>
>>>>> On 03/11/2010 06: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} ..."
>>>>>>
>>>>>
>>>>> I think there is value in keeping to a URL-friendly
>>>>
>>>> Could you please elaborate on this?
>>>
>>> I mean avoiding characters that are not allowed in URLs, in particular
>>> spaces which are troublesome in a variety of contexts. However I if the
>>> spaces are optional (I think they are given that there are always other
>>> separators involved ,:{} then that may not be an issue.
>>
>> Alan I think we should treat the "Broker" portion of it as a URL and
>> the key : value pairs separately.
>> IMO opinion they are two distinct entities that should be treated
>> separately.
>>
>
> 1. You need a URL parser to parse the broker part, migth as well use it
> for the whole thing.
>
> 2. You're going to want to pass these strings around by various means
> outside of qpid (filesystem, program arguments, web pages, other XML
> docs...) URL strings are well known and easy to pass around. Strings
> with custom syntax and embedded spaces will pose a variety of problems -
> you'll end up having to use some form of quoting, URL syntax provides
> this for you.
>
> I'll go one step further and suggest that we should use the standard
> query-string syntax for name/value pairs:
>
> tcp://localhost:8672/?ssl=true&sasl-mech=EXTERNAL&ssl-trust-store=~/cert.jks
> ...
>
> Every URL parser out there already knows how to parse this.
>
> I'll go another step further and propose that we modify the new address
> string format to be URL friendly.
> I see 2 issues: spaces and ';'
>
> I think spaces is a non issue as you can just leave them out - am I
> correct on that?
>
> The issue with ';' is that URLs use it as a separator (alternative to
> '&') in the query string. I suggest we simply drop it. Then we can
> easily embed addresses in URLS, e.g.
>
> tcp://localhost:8672/?ssl=true;sasl-mech=EXTERNAL;address=myqueue{create:always,node-properties:{durable:true}}
> ...
I don't think we can really remove the ';'. The name/subject part of the
address can include fairly complex patterns that include curly braces,
so we really need something to separate the options from the address,
and ';' is pretty much the only reasonable option for this given the
syntax for what goes on either side.
The address syntax was specifically chosen because the URL syntax is
insufficiently powerful to be able to reasonably express everything that
needs to be able to go into an address, things like nested maps/lists,
embedded selector strings, etc. The address syntax is pretty much a pure
subset of python dictionary syntax, so it's always going to be more
expressive than what will be able to naturally fit in a URL.
Personally I think if we nest it's more natural to do it the other way
around. Nest the more limited syntax inside the more powerful one. This
is trivial: {url: "foo://bar.baz.qux"}. You're always going to have
problems if you try to nest the other way around.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
URL-friendly address syntax [ was Re: Client configuration & Connection
URL]
Posted by Alan Conway <ac...@redhat.com>.
On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
> On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway<ac...@redhat.com> wrote:
>> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>>
>>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@redhat.com> wrote:
>>>>
>>>> On 03/11/2010 06: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} ..."
>>>>>
>>>>
>>>> I think there is value in keeping to a URL-friendly
>>>
>>> Could you please elaborate on this?
>>
>> I mean avoiding characters that are not allowed in URLs, in particular
>> spaces which are troublesome in a variety of contexts. However I if the
>> spaces are optional (I think they are given that there are always other
>> separators involved ,:{} then that may not be an issue.
>
> Alan I think we should treat the "Broker" portion of it as a URL and
> the key : value pairs separately.
> IMO opinion they are two distinct entities that should be treated separately.
>
1. You need a URL parser to parse the broker part, migth as well use it for the
whole thing.
2. You're going to want to pass these strings around by various means outside of
qpid (filesystem, program arguments, web pages, other XML docs...) URL strings
are well known and easy to pass around. Strings with custom syntax and embedded
spaces will pose a variety of problems - you'll end up having to use some form
of quoting, URL syntax provides this for you.
I'll go one step further and suggest that we should use the standard
query-string syntax for name/value pairs:
tcp://localhost:8672/?ssl=true&sasl-mech=EXTERNAL&ssl-trust-store=~/cert.jks ...
Every URL parser out there already knows how to parse this.
I'll go another step further and propose that we modify the new address string
format to be URL friendly.
I see 2 issues: spaces and ';'
I think spaces is a non issue as you can just leave them out - am I correct on that?
The issue with ';' is that URLs use it as a separator (alternative to '&') in
the query string. I suggest we simply drop it. Then we can easily embed
addresses in URLS, e.g.
tcp://localhost:8672/?ssl=true;sasl-mech=EXTERNAL;address=myqueue{create:always,node-properties:{durable:true}}
...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway <ac...@redhat.com> wrote:
> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>
>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@redhat.com> wrote:
>>>
>>> On 03/11/2010 06: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} ..."
>>>>
>>>
>>> I think there is value in keeping to a URL-friendly
>>
>> Could you please elaborate on this?
>
> I mean avoiding characters that are not allowed in URLs, in particular
> spaces which are troublesome in a variety of contexts. However I if the
> spaces are optional (I think they are given that there are always other
> separators involved ,:{} then that may not be an issue.
Alan I think we should treat the "Broker" portion of it as a URL and
the key : value pairs separately.
IMO opinion they are two distinct entities that should be treated separately.
The Connection **String** is just a convenient way of expressing them together.
The broker part is to figure out where the broker is and the latter is
to configure the client options, but scoped by the given connection.
I really don't see any advantage in treating the whole string as a URL.
Perhaps I missed something?
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Alan Conway <ac...@redhat.com>.
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@redhat.com> wrote:
>> On 03/11/2010 06: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} ..."
>>>
>>
>> I think there is value in keeping to a URL-friendly
> Could you please elaborate on this?
I mean avoiding characters that are not allowed in URLs, in particular spaces
which are troublesome in a variety of contexts. However I if the spaces are
optional (I think they are given that there are always other separators involved
,:{} then that may not be an issue.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway <ac...@redhat.com> wrote:
> On 03/11/2010 06: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} ..."
>>
>
> I think there is value in keeping to a URL-friendly
Could you please elaborate on this?
>. Can the new address
> format always be expressed without spaces? Seems like it can, E.g.
> tcp://localhost:8672/{ssl:true,sasl-mech:EXTERNAL,ssl-trust-store:~/cert.jks}
Yes - I added the spaces to make it more readable
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Alan Conway <ac...@redhat.com>.
On 03/11/2010 06: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} ..."
>
I think there is value in keeping to a URL-friendly. Can the new address format
always be expressed without spaces? Seems like it can, E.g.
tcp://localhost:8672/{ssl:true,sasl-mech:EXTERNAL,ssl-trust-store:~/cert.jks}
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Mar 15, 2010 at 4:25 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/15/2010 05:48 PM, Rajith Attapattu wrote:
>>
>> On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim<gs...@redhat.com> wrote:
>>>
>>> On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
>>>>
>>>> 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.
>
> Understood. I am responding by pointing out that there is a url scheme
> defined in the 0-10 specification which is currently used by the c++ client.
> The question of whether we want to support that more widely seems to me to
> be worth answering early in any proposal around unification of url schemes
> (whichever way we answer it).
Actually the Java client did support the 0-10 URL format at one point.
But then it got dropped for reasons I can't clearly remember.
Perhaps the archives and svn log might yield some clues.
>> The connection "URL" has been used for two reasons.
>> 1) To identify which broker(s) to connect to
>> 2) As a configuration mechanism.
>
> Isn't the former a specific case for the latter?
It is and as you have mentioned below, the URL is infact one of the
options in the connection String.
However in my proposal I gave it a prominent place by moving it out of
the curly brackets.
>> 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.
>
> You could of course view the url as one of the set of options that can be
> configured via the key-value pairs...
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Gordon Sim <gs...@redhat.com>.
On 03/15/2010 05:48 PM, Rajith Attapattu wrote:
> On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim<gs...@redhat.com> wrote:
>> On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
>>> 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.
Understood. I am responding by pointing out that there is a url scheme
defined in the 0-10 specification which is currently used by the c++
client. The question of whether we want to support that more widely
seems to me to be worth answering early in any proposal around
unification of url schemes (whichever way we answer it).
> The connection "URL" has been used for two reasons.
> 1) To identify which broker(s) to connect to
> 2) As a configuration mechanism.
Isn't the former a specific case for the latter?
> 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.
You could of course view the url as one of the set of options that can
be configured via the key-value pairs...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rajith Attapattu <ra...@gmail.com>.
Cliff,
Sorry about the late reply.
Thanks a lot for the detailed explanation.
All though we strive to have common formats such as a common URL
scheme, address format, API etc..for all the clients, I think it is
reasonable to expect differences as certain clients will have to
follow the established standards, idioms for a particular language.
The other prime example is JMS. And as you said WCF programmers are
used to the paradigm and will understand why it wasn't possible.
Regards,
Rajith
On Tue, Mar 16, 2010 at 2:52 AM, Cliff Jansen (Interop Systems Inc)
<v-...@microsoft.com> wrote:
> Hi Rajith,
>
>> I think we as a project *must* have the same connection url/string
>> syntax across all clients.
>
> I don't think this works in the WCF context. But I believe it is
> merely because WCF has different conventions, not that the proposal
> lacks merit in general.
>
> In WCF, the constituents of the proposed connection string are
> traditionally split apart, not least because the bits of the string
> would be looked at and applied at different times.
>
> The specifics of specifying (e.g. TLS and SASL PLAIN) connection
> related parameters in the WCF/C++ client is a work in progress, so I
> don't have a handy example. But as an analogy, using TLS with a
> client side certificate for the WCF TCP binding:
>
> NetTcpBinding b = new NetTcpBinding();
> b.Security.Mode = SecurityMode.Transport; // versus "None", i.e. no TLS
> b.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate;
> EndpointAddress a = new EndpointAddress("net.tcp://contoso.com/TcpAddress");
> ChannelFactory<ICalculator> cf = new ChannelFactory<ICalculator>(b, a);
> cf.Credentials.ClientCertificate.SetCertificate(
> StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint,
> myCertThumbprintId);
>
> (extracted from http://msdn.microsoft.com/en-us/library/ms729700.aspx,
> which contains the config file too; other WCF bindings have their own
> specific XyzSecurity and XyzCredentialType classes)
>
> There is an expectation that the transport security mode is set up in
> a separate object, which is associated with the binding, and that the
> credentials (if any) are associated with the channel factory (of which
> there could be many for each binding instance, each with separate
> credentials).
>
> Similarly, this division flows to the config file with the security
> mode and credentials separated into unrelated "bindings" and
> "behaviors" XML config sections, respectively (detailed in the link
> above).
>
> This division has its detractors. Obtuse programming gymnastics can
> be necessary in certain cases, such as where separate credentials are
> required by separate layers of the stack (i.e. message versus
> transport security, or if the messages pass through a server proxy).
> However, WCF programmers are used to this paradigm.
>
> Note that any attempt to use the System.ServiceModel.EndpointAddress
> class (above) to combine these properties into a single string would
> fail whenever the string fails to parse into a valid URI, long before
> the Qpid transport layer gets called.
>
> Cliff
>
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> Sent: Monday, March 15, 2010 10:48 AM
> To: dev@qpid.apache.org
> Subject: Re: Client configuration & Connection URL
>
> On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim <gs...@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-subscribe@qpid.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
RE: Client configuration & Connection URL
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
Hi Rajith,
> I think we as a project *must* have the same connection url/string
> syntax across all clients.
I don't think this works in the WCF context. But I believe it is
merely because WCF has different conventions, not that the proposal
lacks merit in general.
In WCF, the constituents of the proposed connection string are
traditionally split apart, not least because the bits of the string
would be looked at and applied at different times.
The specifics of specifying (e.g. TLS and SASL PLAIN) connection
related parameters in the WCF/C++ client is a work in progress, so I
don't have a handy example. But as an analogy, using TLS with a
client side certificate for the WCF TCP binding:
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.Transport; // versus "None", i.e. no TLS
b.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate;
EndpointAddress a = new EndpointAddress("net.tcp://contoso.com/TcpAddress");
ChannelFactory<ICalculator> cf = new ChannelFactory<ICalculator>(b, a);
cf.Credentials.ClientCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint,
myCertThumbprintId);
(extracted from http://msdn.microsoft.com/en-us/library/ms729700.aspx,
which contains the config file too; other WCF bindings have their own
specific XyzSecurity and XyzCredentialType classes)
There is an expectation that the transport security mode is set up in
a separate object, which is associated with the binding, and that the
credentials (if any) are associated with the channel factory (of which
there could be many for each binding instance, each with separate
credentials).
Similarly, this division flows to the config file with the security
mode and credentials separated into unrelated "bindings" and
"behaviors" XML config sections, respectively (detailed in the link
above).
This division has its detractors. Obtuse programming gymnastics can
be necessary in certain cases, such as where separate credentials are
required by separate layers of the stack (i.e. message versus
transport security, or if the messages pass through a server proxy).
However, WCF programmers are used to this paradigm.
Note that any attempt to use the System.ServiceModel.EndpointAddress
class (above) to combine these properties into a single string would
fail whenever the string fails to parse into a valid URI, long before
the Qpid transport layer gets called.
Cliff
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Monday, March 15, 2010 10:48 AM
To: dev@qpid.apache.org
Subject: Re: Client configuration & Connection URL
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim <gs...@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-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim <gs...@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-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Gordon Sim <gs...@redhat.com>.
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.
The approach for specifying SSL is also different across the different
clients.
> 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?
> =========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-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 19, 2010 at 8:23 AM, Rafael Schloming <ra...@redhat.com> wrote:
> I think the first step we need to take before actually thinking about the
> syntax is to put together a matrix with all the connection parameters for
> all the clients.
>
> Historically we've picked a common syntax (URL) but not really bothered to
> ensure that we use the syntax the same way. This is in part because the
> different clients support different options or different ways of
> semantically expressing the same option, so I think the first step is to
> actually align the semantics of the different client connection options so
> that there is actually some benefit to using the same syntax.
>
> Also, I think once we do that it will be easier to see what the requirements
> for the syntax are and whether URL or something more expressive is a better
> fit.
>
> I'm actually futzing with a few of the connection options for the python
> client now, but when I finish with that I'll post a complete list for the
> python client.
+1
I think it's a very sensible step to first figure out the requirements
for each client.
I will create a wiki page and add the Java client stuff.
Regards,
Rajith
> --Rafael
>
> 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}
>>
>> 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}"
>>
>> =========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-subscribe@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: Client configuration & Connection URL
Posted by Rafael Schloming <ra...@redhat.com>.
I think the first step we need to take before actually thinking about
the syntax is to put together a matrix with all the connection
parameters for all the clients.
Historically we've picked a common syntax (URL) but not really bothered
to ensure that we use the syntax the same way. This is in part because
the different clients support different options or different ways of
semantically expressing the same option, so I think the first step is to
actually align the semantics of the different client connection options
so that there is actually some benefit to using the same syntax.
Also, I think once we do that it will be easier to see what the
requirements for the syntax are and whether URL or something more
expressive is a better fit.
I'm actually futzing with a few of the connection options for the python
client now, but when I finish with that I'll post a complete list for
the python client.
--Rafael
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}
>
> 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}"
>
> =========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-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org