Re: [java] Adding support for the new address format in the JMS client

[Rafael Schloming <ra...@redhat.com>]

Robert Godfrey wrote:
> 2
> 
>>> Yep - I have no concerns about that - thanks!
>>>
>>> Now... as to having to use a -D on the JVM to choose which URL format to
>>> use... :-)
>>>
>>> -- Rob
>> are you planning to create more work for me ? :)
>> We could certainly dynamically figure out which format to use.
>> Now the question is are we planning to allow both old and new formats
>> to be used side by side?
>> Or do we need to make this a configurable policy?
>> Perhaps that could be done using a -D option?
>> Something like -Dqpid.dest.format = {URL,Address,Both}
>> I am happy with either 'Address' or 'Both' being the default .
>>
>> What do you think?
>>
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>>
> My view is just that we should try to keep things off the command-line / -D
> parameters as it makes things harder to use... plus there is no reason why
> you might not be mixing old style and new style URLs in the same JVM
> (especially if you're running in a container or something like that).
> 
> If we can make the syntax unambiguous so that the code can identify which
> format it is looking at I think that would be best...

I don't think it's possible to make the syntax unambiguous as you can 
have pretty much arbitrary characters in queue names. As I mentioned 
before we could have some sort of meta-syntax, e.g. "OLD:..." and 
"NEW:..." and we could have a default for addresses that don't start 
with "OLD:" or "NEW:", but I don't think there is an easy way to just 
look at an unadorned address and figure out which syntax it follows, and 
even if this were possible, I think it could possibly be confusing since 
you might have very similar looking addresses in both formats, but with 
different semantics.

I think this will probably benefit from having the formal grammar for 
the new syntax posted, but unfortunately I probably won't get around to 
that until sometime well after turkey.

--Rafael


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

Re: [java] Adding support for the new address format in the JMS client

[Rafael Schloming <ra...@redhat.com>]

Rafael Schloming wrote:
> Robert Godfrey wrote:
>> 2
>>
>>>> Yep - I have no concerns about that - thanks!
>>>>
>>>> Now... as to having to use a -D on the JVM to choose which URL 
>>>> format to
>>>> use... :-)
>>>>
>>>> -- Rob
>>> are you planning to create more work for me ? :)
>>> We could certainly dynamically figure out which format to use.
>>> Now the question is are we planning to allow both old and new formats
>>> to be used side by side?
>>> Or do we need to make this a configurable policy?
>>> Perhaps that could be done using a -D option?
>>> Something like -Dqpid.dest.format = {URL,Address,Both}
>>> I am happy with either 'Address' or 'Both' being the default .
>>>
>>> What do you think?
>>>
>>> Regards,
>>>
>>> Rajith Attapattu
>>> Red Hat
>>> http://rajith.2rlabs.com/
>>>
>>>
>> My view is just that we should try to keep things off the command-line 
>> / -D
>> parameters as it makes things harder to use... plus there is no reason 
>> why
>> you might not be mixing old style and new style URLs in the same JVM
>> (especially if you're running in a container or something like that).
>>
>> If we can make the syntax unambiguous so that the code can identify which
>> format it is looking at I think that would be best...
> 
> I don't think it's possible to make the syntax unambiguous as you can 
> have pretty much arbitrary characters in queue names. As I mentioned 
> before we could have some sort of meta-syntax, e.g. "OLD:..." and 
> "NEW:..." and we could have a default for addresses that don't start 
> with "OLD:" or "NEW:", but I don't think there is an easy way to just 
> look at an unadorned address and figure out which syntax it follows, and 
> even if this were possible, I think it could possibly be confusing since 
> you might have very similar looking addresses in both formats, but with 
> different semantics.
> 
> I think this will probably benefit from having the formal grammar for 
> the new syntax posted, but unfortunately I probably won't get around to 
> that until sometime well after turkey.

It's after turkey, and as promised I've attached a formal grammar and a 
brief description of the semantics for addresses.

--Rafael