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. 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 > > > > >
