2009/12/15 Rafael Schloming <rafa...@redhat.com>:
> 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)...)?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-subscr...@qpid.apache.org > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
