On 24/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
Hi,
As we are doing a bit a re-factoring for the new 0.10 client I would
suggest that we re-evaluate our JMS URL convention.
I would like to simplify the current one and use the following
protocols:
- amqp://host:port/virtual_host
- loopback://virtual_host
In addition to that we would use the following properties:
- amqp.transportType with default value "tcp" (at the minute we are only
supporting this type)
- amqp.encryption with currently supported values "plain", "ssl";
default = plain
Regarding clustering I would suggest that we use the properties:
amqp.brokerURL.1; amqp.brokerURL.2; ... ; amqp.brokerURL.n
When specific transport type or/and encryption must be used we would
also add the corresponding indexed properties i.e.
amqp.encryption.2=ssl
For security we would also use properties:
amqp.username; amqp.password; amqp.keystore etc.
Regarding destinations, I would suggest that we provide a simple admin
class that let create/delete queues and topics. I would not provide
support for declaring destination as JNDI properties. When a destination
is looked up I would check with the broker that this destination
exists.
Arnaud
Arnaud,
I'm not exactly sure what advantage this would give us over the
current ConnectionURL syntax.
I don't see how you would convert the following URL in the current
format to the what you suggest above:
connectionfactory.local =
amqp://guest:[EMAIL
PROTECTED]/test?brokerlist='vm://:1;tcp://localhost:5672;sctp://host:port'
I can see that the extraction of SSL specific properties and the
creation of a SSLConfiguration has not been implemented in the
AMQBrokerDetails object but that would be an easy change as the
SSLConfiguration only takes a few key/value pairs that are already
parsed with the current code.
As for Destinations, the client should be able to access JNDI and
extract a Destination that does not exist on a given broker. When we
created the current mechanism we wanted a simple and extensible system
to allow the Java client to be able to access all the functionality of
AMQP exchanges through JMS. As such our current BindingURL (terrible
naming, my fault) provides the ability for JMS to use all the current
AMQP exchanges, including the Headers exchange.
What would the benefit of performing the broker destination lookup
when performing the JNDI Conext lookup? What connection details would
use to connect to the broker and perform that lookup? Are you
suggesting that destinations are associated with a broker?
--
Martin Ritchie
