On Wed, 2007-07-25 at 16:34 +0100, Martin Ritchie wrote: > 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>']*] >
The point I am making is that using properties would simplify the most common URLs. Moreover, we cannot think about everything so if we want to add staff I think that is easier and more natural to add additional properties rather than extending the URL. > > > 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? Maybe I don't have the same view than you regarding failover. To me you would failover between nodes of a cluster i.e. the brokers are conceptually identical. This means that for the client point of view this does not matter which node it is talking to. Hence, I would have a single connection factory that creates a Qpid connection that knows how to failover between the cluster nodes. Are you seeing failover differently? > 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. I get your point now. I had in mind that in the JMS world you would have to use a management tool to create the destination on your broker. I don't really like the approach of creating the destination when a consumer is created. I would prefer to keep your approach but to create the destinations when the connection factory is created. I would moreover provide a simple management tool for people that are JMS nostalgic (this would also help providing simple samples). Arnaud
