Re: [java] Adding support for the new address format in the JMS client

[Rajith Attapattu <ra...@gmail.com>]

On Wed, Nov 25, 2009 at 6:06 PM, Rafael Schloming <ra...@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?

It's pretty much all the public methods currently present in AMQDestination.
It is ugly no doubt, but changing any public methods that are widely
used in the code base will result in quite bit of work in AMQSession,
BMProducer/Consumer .etc.
For the Address based Destination the most of the methods in
AMQDestionation will make no sense at all.
So we would need to workout a proper interface at a later point as
mentioned in item 6.
My goal is to make changes incrementally. This way people have a reasonably
sized delta to deal with when reviewing work etc.
If we tinker with the interface right way I am afraid the diff would
be quite large and may not get the proper scrutiny it should.

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

think we could use the destination.<jndi-name> = "new address"
format to support the JNDI form.
And createQueue()/createTopic() could also take the new address format
as a string.

As for the new and old syntax we could use a system property as you suggested.
For simplicity we could allow only one format at a time.
If so what should be a sensible default? I'd suggest having the new
format the default to encourage new users to actively use it.


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

As mentioned above I think it's best to allow only one syntax at a time.
Supporting both side-by-side may require a bit more work and the
difference in behaviour may be confusing especially during debug etc..

I'd all also be interested in knowing about other migrations options
or alternative strategies.

> --Rafael
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org