Hi Rajith, Thanks.
So if an existing user upgrades, but forgets/doesn't know to change the default preifx then they'll get a parsing exception or suchlike back when they try to connect ? Marnie On Mon, Dec 14, 2009 at 8:16 PM, Rajith Attapattu <rajit...@gmail.com>wrote: > 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 > >
