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. > 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 > 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. > 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. Arnaud
