On Mon, Dec 14, 2009 at 2:59 PM, Marnie McCormack <marnie.mccorm...@googlemail.com> wrote: > I'm glad to read about plans for supporting both syntaxes going forward, and > providing backward compatibility. > > I'm not grasping how prefixing aids migration for existing users (or maybe > I've misunderstood what the prefix is intended to provide) ? If they have to > edit/test their connection config then I don't think that'll help.
The prefix is important if people plan to use both the new and old format side by side. If an entry has no prefix, it will be interpreted according to the default prefix (which could be overridden with connection property or JVM argument). For the initial release we should have BURL as the default prefix. So existing users will need to do zero config to upgrade. For subsequent releases we should change the default prefix to ADDR. That way people who use the new format gets the benefit of not having to explicitly denote a prefix. For existing users they would need to add the prefix or change the default prefix. Regards, Rajith > I like Gordon's suggestion as a way of addressing this and allowing > migration for users on the old style. > > Regards, > Marnie > > > > > On Thu, Dec 10, 2009 at 9:39 PM, Rafael Schloming <rafa...@redhat.com>wrote: > >> Gordon Sim wrote: >> >>> On 11/25/2009 11:06 PM, Rafael Schloming wrote: >>> >>>> One question I have is about how we'll provide access to alternate >>>> syntaxes via jndi configuration and the JMS API (i.e. >>>> createQueue(...)/createTopic(...)). I can think of a few options, e.g. >>>> switching between syntaxes using a system/connection property. Or maybe >>>> having some sort of meta-syntax that that would permit usage of the two >>>> syntaxes side by side, e.g. "OLD: ...", "NEW: ...", or possibly some >>>> combination of the two approaches. >>>> >>> >>> In the case of jndi configuration, what about having a different context >>> factory to do the parsing? I.e. in jndi configuration files using the new >>> syntax you would specify something other than the existing >>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way existing >>> configuration will work as before with no changes, and a new format can be >>> parsed without any need to worry about the older format. >>> >>> That doesn't deal with strings passed to createQueue()/createTopic() of >>> course. Perhaps there a specific 'factory' can be associated with a >>> connection, configured via a connection option? Where a file backed jndi >>> configuration is used the two different context factories could then set >>> different defaults for this meaning again that old config would be >>> unaffected and new config could ignore the old config entirely also. >>> >>> Just a suggestion... >>> >> >> I've been thinking we should just do something like: >> >> "ADDR: ..." gets parsed as an address (after removing the ADDR:) >> "BURL: ..." gets parsed as a binding url (after removing the BURL:) >> >> and anything not starting with ADDR: or BURL: gets parsed as one or the >> other according to some default that is configurable at the connection, >> context factory, and JVM levels. >> >> --Rafael >> >> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> >> > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
