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:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
