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).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
