On 26/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
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'm not so sure that building such defaults into our client code /
broker is that wise as somewhere someone will not realise and access
will be leaked.
You continue to miss out the client ID which is required to identify
the connected clients for such things as durable subscriptions.
Is this url really too difficult for your users to understand?
amqp://guest:[EMAIL PROTECTED]/virtualhost?brokerlist='localhost'
I've helped a number of novice JMS people to write apps none have
commented on the JNDI configuration.
Did the documentation page not help at all?
http://cwiki.apache.org/qpid/how-to-use-jndi.html
> 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.
As much as I love writing little tools I do think though we have a
rather large work load implementing the core functionality for 0_10.
But every little helps. :)
> 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
I think the 0_10 client should utilise a System property to cause the
client framework to declare or not declare connections. We don't want
to force our users to use JNDI.
--
Martin Ritchie
