As someone who is actively using 0-10 JMS clients in production :-)
I'd definitely vote for keeping existing behaviour in place where
possible.
If it's not possible to keep existing apis in place, I'd definitely
vote for 'sharp' api changes rather than -D style system properties
configs. (Assuming the c++ broker support both types of client
simultaneously - apps could migrate on independent release cycles). As
I think someone mentioned, this is much friendlier for container-based
apps.
Cheers,
Andrew
On 26 Nov 2009, at 15:54, Rajith Attapattu wrote:
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
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
