Rafael Schloming wrote:
Jonathan Robie wrote:
Rafael Schloming wrote:
There really are two separate configuration topics here:
configuration of the client (which is reasonable to do via JNDI) and
configuration of the broker (which nobody in their right mind would
ever consider doing via JNDI). It would probably be helpful clarify
which one you mean in a given context.
The Java JMS examples we use configure the broker - they set up
queues and bindings in the broker. What's our story here - is this
something that nobody in their right mind would actually do? If so,
we might want to change this in our examples once we provide better
alternatives ....
Yes, this is pretty much insane since you need to separately specify
your broker schema for each client that connects, and if they don't
all match (e.g. one has a typo) then who knows what you'll end up
getting. It's a race where the first client to connect wins.
Not to mention it's woefully incomplete as a mechanism to configure
the broker, e.g. there is no way to delete the queues and bindings you
create this way.
In general you should have a single well documented schema for the
broker that is maintained separately from all the clients, and the
clients should be configured with the minimal information required to
connect to this schema, i.e. just the relevant queue or topic name.
That's how the examples in other languages work - there is a separate
program that sets up the configuration, a publisher that sends messages,
and a consumer that reads messages from a queue.
Private queues (exclusive + autodelete) are treated differently, the
client configures these queues and the associated bindings, even though
the queues live on the broker. And these queues rather belong to the
client - I assume we want to make sure the client can configure them. In
other languages, I imagine they just use the configuration API for this.
What's the best way to handle this in Java JMS?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
