qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject Re: [java] Adding support for the new address format in the JMS client
Date Tue, 15 Dec 2009 09:12:30 GMT
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"));

> I'm suggesting that the createQueue()/createTopic() behaviour be configured
> through a flag/mode on the connection and that when jndi is used to obtain a
> connection factory the value of that flag/mode could be different based on
> the context factory in use.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>



-- 
Martin Ritchie

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message