On Thu, 2007-07-26 at 12:58 +0100, Martin Ritchie wrote: > Is adding option=value to the end of a url really more complex than > putting it on a new line? > > I would say that you would require more information in the new line > approach so that you can associate that option to the specific > connnectionfactory defined in the file.
You may be right, I was thinking about simplifying the URL scheme based on feedback I had from non-expert people trying to write a "hello word" JMS application. Would it be acceptable for you if we keep the existing scheme but also accept URL of type: amqptcp://host:port/virtual_broker that uses all the default properties i.e.: tcp, guest, guest with a single broker. The name "amqptcp" is bad, I am sure we'll find a better name. So we would have the advance URL for advance users and a simple scheme for beginners that we can use to write samples. What do you think about that? > I don't think I'm seeing failover differently but I think we are > seeing the JNDI properties file differently. I see one file with a > number of connectionfactories defined that can be used to connect to a > number of different clusters. Hence that connection factory needs to > know all the broker details associated with that connection/cluster. > From what you are saying would I be correct in thinking that you see > the JNDI properties file with at most a single cluster defined. You are right, I was seeing a one to one mapping between a cluster and a JNDI property file. > I agree that having a tool to create queues/topics/destinations on the > broker would be helpful as that is what people expect when migrating > from other messaging products. The current automatic declaration is a > convenience for JMS users. Great, it should be simple enough to provide such a tool by using the new JAVA Qpid APi. > However that said looking up a JNDI object doesn't cause any creation > on the broker. I did h ave a patch to commit to add a System Property > which would stop the client performing exchange/queue declare for each > new consumer. So if the queues didn't exist they would get an error. > It appears I forgot to commit it :) (more likely hadn't fully tested > it) > > When we have full ACLs on the broker then would have no need for this > as the client would have to have permission to declare > queues/exchanges. So some sort of tool will be required at that stage. So, should we say that the 0.10 client does not dynamically create destinations (apart form temporary ones obviously) or that it tries of declaring destination that are defined in the JNDI properties file? I think that both approaches would be acceptable. Thanks Arnaud
