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, 01 Dec 2009 00:25:11 GMT
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.


View raw message