qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [java] Adding support for the new address format in the JMS client
Date Tue, 15 Dec 2009 09:23:04 GMT
Martin Ritchie wrote:
> 2009/12/15 Gordon Sim <gsim@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<ritchiem@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-subscribe@qpid.apache.org


Mime
View raw message