Martin Ritchie wrote:
2009/12/15 Gordon Sim <g...@redhat.com>:
On 12/15/2009 08:46 AM, Rafael Schloming wrote:
Gordon Sim wrote:
On 12/15/2009 08:07 AM, Rafael Schloming wrote:
Gordon Sim wrote:
On 12/15/2009 12:03 AM, Aidan Skinner wrote:
On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ritch...@apache.org>
wrote:
What ever we do new JNDI, prefixing (which I find a tad strange) we
need to support both formats simultaneously in a single file to allow
users to migrate.
Mixing formats in one file seems unlikely. Wouldn't users change all
the urls in their file at once?
That would be my view also.
Using different context factories for the parsing seems like the best
solution to me. It does mean that users have to change code as well as
configuration when switching over.
I think they would only need to change code if they were passing
binding urls to createQueue()/createTopic(). If they were only passing
straight queue names (or topic names) then I don't think any change
should be necessary to their code. Unless of course I am missing
something?
The semantics of createQueue("foo") depend on whether "foo" is
interpreted as an address or not. Under the current semantics this would
automatically declare the queue on the server. If interpreted as an
address, you would need to supply "foo; {create: always, assert:
always}" in order to get equivalent semantics.
Good point. However as long as users get the same semantics if they
use the same config file from before (i.e. the old/existing context
factory), and as long as we document this subtle shift then I think
its acceptable to have any use of createQueue()/createTopic() revised
when switching over to the new context factory. (Where JNDI is not
used, a flag on the connection that determines whether the value
passed in should be treated as a binding url or an address would work).
Are you suggesting that createQueue()/createTopic() behavior would
somehow be modified by setting the jndi context factory?
I don't think this is something we should be doing. If users want to
load a JNDI value for createQueue then there are already mechanism for
doing that which should be used:
createQueue((Queue)initialContext.lookup("foo"));
Unless I'm missing something, there is no createQueue() that takes a
Queue. Did you mean createConsumer((Queue)...)?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
