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
