On 25/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
On Wed, 2007-07-25 at 10:16 +0100, Martin Ritchie wrote:
> I'm not exactly sure what advantage this would give us over the
> current ConnectionURL syntax.
The aim was to simplify the current approach.
Just so we are all clear this is the current approach
url=amqp://[<user>:<pass>@][<clientid>]/<virtualhost>?brokerlist='<brokerdetail>[;[<brokerdetail>]'
brokerdetail=<protocol>://<host>[:<port>][[?<option>='<value>'],[<option>='<value>']*]
> 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'
It would be:
connectionfactory=amqp://localhost:5672/test
amqp.clientId=clientid
amqp.brokerURL.2=amqp://host:port/test
amqp.transportType.2=sctp
amqp.encryption.2=ssl
But this has no vm://:1 nor any relationship between items. what if I had
connectionfactory2=amqp://specialhost:4564/private
Would the two clients using this connection factory use the same amqp.clientId?
How would failover work, would both connectionfactories use
brokerURL.2 as a failover host?
> 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.
That can be achieved through a simple management API. The aim agian is
to simplify the URL that is very complicated.
Again for clarity here is our current BindingURL
<exch_class>://<exch_name>/[<destination>]/[<queue>][[?<option>='<value>'][,<option>='<value>']*]
> 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?
I was not suggesting that. I was saying that we should provide a
destination management AP instead of including everything in the URL.
I'm not sure if I follow how this would work. Our current setup allows
for the JMS Destination that is being used by a client to be altered
with zero code changes. This Is this something that a destination
management API would also need to allow.
Arnaud
Arnaud,
What is it about the current URL formats that is very complicated? Can
we address this first if this is what is driving you to suggest an
alternative format.
We settled on the current format as it captured all the required
information to perform a connection along with any required failover
information.
Whilst the BindingURLs can seem a little verbose for use in the JNDI
property file this was because the BindingURLs original goal was to
allow broker bootstrapping. That said their use in the JNDI file
should be straightforward.
--
Martin Ritchie
