On Thu, Nov 26, 2009 at 6:16 AM, Robert Godfrey <rob.j.godf...@gmail.com> wrote: > 2009/11/26 Marnie McCormack <marnie.mccorm...@googlemail.com> > >> Hi Rajith & Rafi, >> >> I should be able to shed some light on the migration implications of this >> change. >> >> To check that I've understood what you're proposing - so the existing >> BindingURL implementation would be used for the 0-8/0-9 codepaths and >> you're >> only writing an impl for the 0-10 path ? >> >> Regards, >> Marnie >> >> >> > I would think this would be a *Bad Thing* > > We want people to be able to swap out an 0-9 broker for an 0-10 broker > without having to reconfigure their clients if possible.
For sure. This is a key requirement. We want people to upgrade from an 0-8/0-9 client to a 0-10 client without changes. And we also want folks to upgrade their existing 0-10 client to a newer version without having to rewrite their configuration. So for the 0-10 code path it will support both formats. Does this answer your question sufficiently? > That's not to say that adding a new URL which would only work on 0-10 and > upwards would be a bad thing... just that we should continue to hav a URL > format that works compatibly across all existing brokers. > > -- Rob > > >> >> On Wed, Nov 25, 2009 at 11:06 PM, Rafael Schloming <rafa...@redhat.com >> >wrote: >> >> > Rajith Attapattu wrote: >> > >> >> Hi All >> >> >> >> I have been thinking about adding support in the JMS client for the >> >> new address format currently implemented in python and c++ by Rafi and >> >> Gordon. >> >> I am exploring the viability of the following approach. Comments and >> >> suggestions are most welcomed. >> >> Please feel free to suggest class names etc. It's not easy coming up >> >> with names :). >> >> >> >> Given that AMQDestination is used all over the code base, I am >> >> thinking about using an incremental approach to minimize disruptions. >> >> I have tried a prototype of this idea and it seems to work reasonably >> >> well. >> >> >> >> 1. Extract an interface from the current AMQDestination class and name >> >> the interface as AMQDestination (which extends the >> >> javax.jms.Destination). >> >> >> > >> > Is it possible for you to post the interface you extracted? >> > >> > >> > 2. The current AMQDestination class will be renamed to >> >> AMQBindingURLDestination which implements AMQDestination >> >> >> >> Step 1 & 2 will ensure that the current code compiles and that >> >> majority of the code remains unchanged. >> >> Since the current AMQDestination abstract class is based on the >> >> binding URL concept I suggest to rename it to AMQBindingURLDestination >> >> >> >> 3. Add an abstract class AMQAddressDestination that implements >> >> AMQDestination. >> >> 4. Add AMQAddressDestination_0_10 >> >> 5. Add support in AMQSession_0_10, BMProducer/Consumer_0_10 to check >> >> if the destination type and support appropriate behaviour. >> >> >> >> Step 3 will add generic support for the new addressing format and step >> >> 4 a mapping to the 0_10 syntax. >> >> Step 5 will provide the required functionality to support the address >> >> format while retaining backwards compatibility. >> >> >> >> 5. Later on we can look at making AMQDestination a proper interface >> >> rather than a stop gap measure. >> >> In order to do this a fair bit of tinkering would be needed in the >> >> AMQSession, BMProducer/Consumer etc.. >> >> >> >> We would obviously need a parser for the new addressing format. >> >> I believe Rafi has volunteered to whip that as he was working on one >> >> for python :) >> >> >> > >> > I'm happy to provide one for Java as well. As a first step I'll document >> > and post the syntax. Writing a Java parser should be quick, I just want >> to >> > get as much feedback as I can first, so that the syntax is as final as >> > possible before doing it. >> > >> > 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. >> > >> > One of the things I'm unsure of here is what we need to provide in terms >> of >> > backwards-compatibility/migration support for our users, e.g. do we need >> to >> > provide the ability to use both syntaxes side-by-side on the same >> > connection, or can we expect people to be using only one syntax or the >> > other? Are there other migration options/issues we should be considering? >> > >> > --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
