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

[Andrew Wright <at...@mac.com>]

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
> <ma...@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 <rafaels@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-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
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org