On Thu, Nov 26, 2009 at 6:03 AM, Marnie McCormack <marnie.mccorm...@googlemail.com> wrote: > 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
Marnie, Actually I am hoping to have support for both formats in the 0-10 client (via a jvm switch) as I am sure there are several folks using 0-10 in production. For time being I only envisioned having the new format for 0-10 and above, as I am not sure that 0-8/0-9 client will necessarily benefit from the new format. Is this fine with you? Regards, Rajith > > > 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
