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:27:38 GMT
2009/12/15 Rafael Schloming <rafaels@redhat.com>:
> 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)...)?

Your right I probably did but also ment that if you want a Queue
Object then JNDI InitialContext gives that to you. Currently if you
actually want the queue to be created on the broker in a pure JMS way
then createConsumer(..) is the only way to go.

Martin

> --Rafael
>
>
> ---------------------------------------------------------------------
> 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