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-subscr...@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
