You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2009/11/25 22:36:19 UTC
[java] Adding support for the new address format in the JMS client
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).
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 :)
How does the above plan sound?
Btw the JIRA for this is QPID-1831
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
Re: [java] Adding support for the new address format in the JMS
client
Posted by 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
Re: [java] Adding support for the new address format in the JMS client
Posted by 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
Re: [java] Adding support for the new address format in the JMS
client
Posted by Robert Godfrey <ro...@gmail.com>.
2009/11/26 Rajith Attapattu <ra...@gmail.com>
> 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?
>
>
A JVM switch seems a fairly unfriendly way of letting the user do this... is
there no way the code could dynamically detect which sort of URL format is
in use?
-- Rob
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <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?
>>
>>
>> 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
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Rafael Schloming wrote:
> Robert Godfrey wrote:
>> 2
>>
>>>> Yep - I have no concerns about that - thanks!
>>>>
>>>> Now... as to having to use a -D on the JVM to choose which URL
>>>> format to
>>>> use... :-)
>>>>
>>>> -- Rob
>>> are you planning to create more work for me ? :)
>>> We could certainly dynamically figure out which format to use.
>>> Now the question is are we planning to allow both old and new formats
>>> to be used side by side?
>>> Or do we need to make this a configurable policy?
>>> Perhaps that could be done using a -D option?
>>> Something like -Dqpid.dest.format = {URL,Address,Both}
>>> I am happy with either 'Address' or 'Both' being the default .
>>>
>>> What do you think?
>>>
>>> Regards,
>>>
>>> Rajith Attapattu
>>> Red Hat
>>> http://rajith.2rlabs.com/
>>>
>>>
>> My view is just that we should try to keep things off the command-line
>> / -D
>> parameters as it makes things harder to use... plus there is no reason
>> why
>> you might not be mixing old style and new style URLs in the same JVM
>> (especially if you're running in a container or something like that).
>>
>> If we can make the syntax unambiguous so that the code can identify which
>> format it is looking at I think that would be best...
>
> I don't think it's possible to make the syntax unambiguous as you can
> have pretty much arbitrary characters in queue names. As I mentioned
> before we could have some sort of meta-syntax, e.g. "OLD:..." and
> "NEW:..." and we could have a default for addresses that don't start
> with "OLD:" or "NEW:", but I don't think there is an easy way to just
> look at an unadorned address and figure out which syntax it follows, and
> even if this were possible, I think it could possibly be confusing since
> you might have very similar looking addresses in both formats, but with
> different semantics.
>
> I think this will probably benefit from having the formal grammar for
> the new syntax posted, but unfortunately I probably won't get around to
> that until sometime well after turkey.
It's after turkey, and as promised I've attached a formal grammar and a
brief description of the semantics for addresses.
--Rafael
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> 2
>
>>> Yep - I have no concerns about that - thanks!
>>>
>>> Now... as to having to use a -D on the JVM to choose which URL format to
>>> use... :-)
>>>
>>> -- Rob
>> are you planning to create more work for me ? :)
>> We could certainly dynamically figure out which format to use.
>> Now the question is are we planning to allow both old and new formats
>> to be used side by side?
>> Or do we need to make this a configurable policy?
>> Perhaps that could be done using a -D option?
>> Something like -Dqpid.dest.format = {URL,Address,Both}
>> I am happy with either 'Address' or 'Both' being the default .
>>
>> What do you think?
>>
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>>
> My view is just that we should try to keep things off the command-line / -D
> parameters as it makes things harder to use... plus there is no reason why
> you might not be mixing old style and new style URLs in the same JVM
> (especially if you're running in a container or something like that).
>
> If we can make the syntax unambiguous so that the code can identify which
> format it is looking at I think that would be best...
I don't think it's possible to make the syntax unambiguous as you can
have pretty much arbitrary characters in queue names. As I mentioned
before we could have some sort of meta-syntax, e.g. "OLD:..." and
"NEW:..." and we could have a default for addresses that don't start
with "OLD:" or "NEW:", but I don't think there is an easy way to just
look at an unadorned address and figure out which syntax it follows, and
even if this were possible, I think it could possibly be confusing since
you might have very similar looking addresses in both formats, but with
different semantics.
I think this will probably benefit from having the formal grammar for
the new syntax posted, but unfortunately I probably won't get around to
that until sometime well after turkey.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Nov 26, 2009 at 11:46 AM, Robert Godfrey
<ro...@gmail.com> wrote:
> 2
>
>> >>
>> > Yep - I have no concerns about that - thanks!
>> >
>> > Now... as to having to use a -D on the JVM to choose which URL format to
>> > use... :-)
>> >
>> > -- Rob
>>
>> are you planning to create more work for me ? :)
>> We could certainly dynamically figure out which format to use.
>> Now the question is are we planning to allow both old and new formats
>> to be used side by side?
>> Or do we need to make this a configurable policy?
>> Perhaps that could be done using a -D option?
>> Something like -Dqpid.dest.format = {URL,Address,Both}
>> I am happy with either 'Address' or 'Both' being the default .
>>
>> What do you think?
>>
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>>
> My view is just that we should try to keep things off the command-line / -D
> parameters as it makes things harder to use... plus there is no reason why
> you might not be mixing old style and new style URLs in the same JVM
> (especially if you're running in a container or something like that).
>
> If we can make the syntax unambiguous so that the code can identify which
> format it is looking at I think that would be best...
>
> -- Rob
Rob my first option is to avoid -D options or any form configuration.
The less you need to tweak options the easy it becomes to migrate etc..
But as Rafi mentioned we may have some difficulties in figuring out
the exact format.
Perhaps we could find a decent solution to the above problem.
I am certainly open to all suggestions.
Lets wait for Rafi's write up and then discuss this further.
I am sure we could arrive at some acceptable solution.
While we work out this issue, is there any objection if I proceed
forward based on the approach highlighted in my first email?
I believe the only issue so far is the agreement on which mechanism is
best to figure out the format.
May I proceed with the other ground work necessary to get this approach moving?
>
>> ---------------------------------------------------------------------
>> 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
Re: [java] Adding support for the new address format in the JMS
client
Posted by Robert Godfrey <ro...@gmail.com>.
2
> >>
> > Yep - I have no concerns about that - thanks!
> >
> > Now... as to having to use a -D on the JVM to choose which URL format to
> > use... :-)
> >
> > -- Rob
>
> are you planning to create more work for me ? :)
> We could certainly dynamically figure out which format to use.
> Now the question is are we planning to allow both old and new formats
> to be used side by side?
> Or do we need to make this a configurable policy?
> Perhaps that could be done using a -D option?
> Something like -Dqpid.dest.format = {URL,Address,Both}
> I am happy with either 'Address' or 'Both' being the default .
>
> What do you think?
>
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
>
My view is just that we should try to keep things off the command-line / -D
parameters as it makes things harder to use... plus there is no reason why
you might not be mixing old style and new style URLs in the same JVM
(especially if you're running in a container or something like that).
If we can make the syntax unambiguous so that the code can identify which
format it is looking at I think that would be best...
-- Rob
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Nov 26, 2009 at 11:02 AM, Robert Godfrey
<ro...@gmail.com> wrote:
> 2009/11/26 Rajith Attapattu <ra...@gmail.com>
>
>> On Thu, Nov 26, 2009 at 6:16 AM, Robert Godfrey <ro...@gmail.com>
>> wrote:
>> > 2009/11/26 Marnie McCormack <ma...@googlemail.com>
>> >
>> >> 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
>> >>
>> >>
>> >>
>> > I would think this would be a *Bad Thing*
>> >
>> > We want people to be able to swap out an 0-9 broker for an 0-10 broker
>> > without having to reconfigure their clients if possible.
>>
>> For sure. This is a key requirement. We want people to upgrade from an
>> 0-8/0-9 client to a 0-10 client without changes.
>> And we also want folks to upgrade their existing 0-10 client to a
>> newer version without having to rewrite their configuration.
>> So for the 0-10 code path it will support both formats.
>>
>> Does this answer your question sufficiently?
>>
>>
> Yep - I have no concerns about that - thanks!
>
> Now... as to having to use a -D on the JVM to choose which URL format to
> use... :-)
>
> -- Rob
are you planning to create more work for me ? :)
We could certainly dynamically figure out which format to use.
Now the question is are we planning to allow both old and new formats
to be used side by side?
Or do we need to make this a configurable policy?
Perhaps that could be done using a -D option?
Something like -Dqpid.dest.format = {URL,Address,Both}
I am happy with either 'Address' or 'Both' being the default .
What do you think?
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
Re: [java] Adding support for the new address format in the JMS
client
Posted by Robert Godfrey <ro...@gmail.com>.
2009/11/26 Rajith Attapattu <ra...@gmail.com>
> On Thu, Nov 26, 2009 at 6:16 AM, Robert Godfrey <ro...@gmail.com>
> wrote:
> > 2009/11/26 Marnie McCormack <ma...@googlemail.com>
> >
> >> 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
> >>
> >>
> >>
> > I would think this would be a *Bad Thing*
> >
> > We want people to be able to swap out an 0-9 broker for an 0-10 broker
> > without having to reconfigure their clients if possible.
>
> For sure. This is a key requirement. We want people to upgrade from an
> 0-8/0-9 client to a 0-10 client without changes.
> And we also want folks to upgrade their existing 0-10 client to a
> newer version without having to rewrite their configuration.
> So for the 0-10 code path it will support both formats.
>
> Does this answer your question sufficiently?
>
>
Yep - I have no concerns about that - thanks!
Now... as to having to use a -D on the JVM to choose which URL format to
use... :-)
-- Rob
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Nov 26, 2009 at 6:16 AM, Robert Godfrey <ro...@gmail.com> wrote:
> 2009/11/26 Marnie McCormack <ma...@googlemail.com>
>
>> 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
>>
>>
>>
> I would think this would be a *Bad Thing*
>
> We want people to be able to swap out an 0-9 broker for an 0-10 broker
> without having to reconfigure their clients if possible.
For sure. This is a key requirement. We want people to upgrade from an
0-8/0-9 client to a 0-10 client without changes.
And we also want folks to upgrade their existing 0-10 client to a
newer version without having to rewrite their configuration.
So for the 0-10 code path it will support both formats.
Does this answer your question sufficiently?
> That's not to say that adding a new URL which would only work on 0-10 and
> upwards would be a bad thing... just that we should continue to hav a URL
> format that works compatibly across all existing brokers.
>
> -- Rob
>
>
>>
>> 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
Re: [java] Adding support for the new address format in the JMS
client
Posted by Robert Godfrey <ro...@gmail.com>.
2009/11/26 Marnie McCormack <ma...@googlemail.com>
> 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
>
>
>
I would think this would be a *Bad Thing*
We want people to be able to swap out an 0-9 broker for an 0-10 broker
without having to reconfigure their clients if possible.
That's not to say that adding a new URL which would only work on 0-10 and
upwards would be a bad thing... just that we should continue to hav a URL
format that works compatibly across all existing brokers.
-- Rob
>
> 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
> >
> >
>
Re: [java] Adding support for the new address format in the JMS
client
Posted by Marnie McCormack <ma...@googlemail.com>.
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
On Wed, Nov 25, 2009 at 11: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?
>
>
> 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
>
>
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> Ok, I must be in need of a break as I don't see why we can't
> automatically detect and parse the formats.
>
> We are talking about the difficulty that the JNDI destination tag will
> be able to be more than one format right?
>
> Old style:
> destination.direct = direct://amq.direct//directQueue
> New Style:
> my-destination; {create: always, node-properties: {type: special}}
>
> as far as I can see the two would be quite easy to distinguish.
>
> Old is
> STRING://STRING/...
> New
> is
> STRING;...
>
> Sorry If I'm clearly not following what is going on but could someone
> explain where the difficulty in detecting the difference between the
> two formats lies?
The string "direct:" is a valid node name, and the string
"/amq.direct//directQueue" is a valid subject. Putting them together
with a slash in between (name/subject) results in:
direct://amq.direct//directQueue
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Martin Ritchie <ri...@apache.org>.
2009/12/11 Rafael Schloming <ra...@redhat.com>:
> Martin Ritchie wrote:
>>
>> 2009/12/10 Rafael Schloming <ra...@redhat.com>:
>>>
>>> Gordon Sim wrote:
>>>>
>>>> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>>>>>
>>>>> 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.
>>>>
>>>> In the case of jndi configuration, what about having a different context
>>>> factory to do the parsing? I.e. in jndi configuration files using the
>>>> new
>>>> syntax you would specify something other than the existing
>>>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way
>>>> existing
>>>> configuration will work as before with no changes, and a new format can
>>>> be
>>>> parsed without any need to worry about the older format.
>>>>
>>>> That doesn't deal with strings passed to createQueue()/createTopic() of
>>>> course. Perhaps there a specific 'factory' can be associated with a
>>>> connection, configured via a connection option? Where a file backed jndi
>>>> configuration is used the two different context factories could then set
>>>> different defaults for this meaning again that old config would be
>>>> unaffected and new config could ignore the old config entirely also.
>>>>
>>>> Just a suggestion...
>>>
>>> I've been thinking we should just do something like:
>>>
>>> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
>>> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
>>>
>>> and anything not starting with ADDR: or BURL: gets parsed as one or the
>>> other according to some default that is configurable at the connection,
>>> context factory, and JVM levels.
>>>
>>> --Rafael
>>
>> Hi Rafi, do you have some examples of your grammar, my cold filled
>> head still doesn't follow why you have to start prefixing things.
>>
>> What ever we do new JNDI, prefixing (which I find a tad strange) wedestination.direct = direct://amq.direct//directQueue
>> need to support both formats simultaneously in a single file to allow
>> users to migrate.
>
> If you want to support both formats simultaneously in a single file, then
> the only practical way I can think of to do that is with some sort of meta
> syntax akin to prefixing. You need some way to clearly and unambiguously
> figure out which parser to invoke, both for the sake of the implementation
> and for the sake of the people reading the file and trying to interpret the
> content.
>
> Please refer to the attached file for an updated the grammar description
> with some examples.
>
> --Rafael
>
>
> Tokens:
>
> LBRACE: r"\{"
> RBRACE: r"\}"
> COLON: r":"
> SEMI: r";"
> SLASH: r"/"
> COMMA: r","
> NUMBER: r'[+-]?[0-9]*\.?[0-9]+'
> ID: r'[a-zA-Z_](?:[a-zA-Z0-9_-]*[a-zA-Z0-9_])?'
> STRING: r""""(?:[^\\"]|\\.)*"|'(?:[^\\']|\\.)*'"""
> ESC:
> r"\\[^ux]|\\x[0-9a-fA-F][0-9a-fA-F]|\\u[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]"
> SYM: r"[.#*%@$^!+-]"
> WSPACE: r"[ \n\r\t]+"
> EOF:
>
> Grammar:
>
> address = name [ "/" subject ] [ ";" options ]
> name = ( part | quoted )+
> subject = ( part | quoted | "/" )*
> quoted = STRING / ESC
> part = LBRACE / RBRACE / COLON / COMMA / NUMBER / ID / SYM
> options = map
> map = "{" ( keyval ( "," keyval )* )? "}"
> keyval = ID ":" value
> value = NUMBER / STRING / ID / map / list
> list = "[" ( value ( "," value )* )? "]"
>
> Semantics:
>
> An address identifies a source or target for messages. In its
> simplest form this is just a name. In general a target address may
> also be used as a source address, however not all source addresses
> may be used as a target, e.g. a source might additionally have some
> filtering criteria that would not be present in a target.
>
> A subject may optionally be specified along with the name. When an
> address is used as a target, any subject specified in the address is
> used as the default subject of outgoing messages for that target.
> When an address is used as a source, any subject specified in the
> address is pattern matched against the subject of available messages
> as a filter for incoming messages from that source.
>
> The options map contains additional information about the address
> including:
>
> - policies for automatically creating, and deleting the node to
> which an address refers
>
> - policies for asserting facts about the node to which an address
> refers
>
> - extension points that can be used for sender/receiver
> configuration
>
> Mapping to 0-10 semantics:
>
> The name is resolved to either an exchange or a queue by querying
> the broker.
>
> The subject is set as a property on the message. Additionally, if
> the name refers to an exchange, the routing key is set to the
> subject.
>
> Examples:
>
> A simple name resolves to any named node, usually a queue or a
> topic:
>
> my-queue-or-topic
>
> A simple name with a subject will also resolve to a node, but the
> presence of the subject will cause a sender using this address to
> set the subject on outgoing messages, and receivers to filter based
> on the subject:
>
> my-queue-or-topic/my-subject
>
> A subject pattern can be used and will cause filtering if used by
> the receiver. If used for a sender, the literal value gets set as
> the subject:
>
> my-queue-or-topic/my-*
>
> In all the above cases, the address is resolved to an existing node.
> If you want the node to be auto-created, then you can do the
> following. By default nonexistent nodes are assumed to be queues:
>
> my-queue; {create: always}
>
> You can customize the properties of the queue:
>
> my-queue; {create: always, node-properties: {durable: True}}
>
> You can create a topic instead if you want:
>
> my-queue; {create: always, node-properties: {type: topic}}
>
> You can assert that the address resolves to a node with particular
> properties:
>
> my-transient-topic; {assert: always, node-properties: {type: topic,
> durable: False}}
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
Ok, I must be in need of a break as I don't see why we can't
automatically detect and parse the formats.
We are talking about the difficulty that the JNDI destination tag will
be able to be more than one format right?
Old style:
destination.direct = direct://amq.direct//directQueue
New Style:
my-destination; {create: always, node-properties: {type: special}}
as far as I can see the two would be quite easy to distinguish.
Old is
STRING://STRING/...
New
is
STRING;...
Sorry If I'm clearly not following what is going on but could someone
explain where the difficulty in detecting the difference between the
two formats lies?
Cheers
Martin
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> 2009/12/10 Rafael Schloming <ra...@redhat.com>:
>> Gordon Sim wrote:
>>> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>>>> 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.
>>> In the case of jndi configuration, what about having a different context
>>> factory to do the parsing? I.e. in jndi configuration files using the new
>>> syntax you would specify something other than the existing
>>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way existing
>>> configuration will work as before with no changes, and a new format can be
>>> parsed without any need to worry about the older format.
>>>
>>> That doesn't deal with strings passed to createQueue()/createTopic() of
>>> course. Perhaps there a specific 'factory' can be associated with a
>>> connection, configured via a connection option? Where a file backed jndi
>>> configuration is used the two different context factories could then set
>>> different defaults for this meaning again that old config would be
>>> unaffected and new config could ignore the old config entirely also.
>>>
>>> Just a suggestion...
>> I've been thinking we should just do something like:
>>
>> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
>> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
>>
>> and anything not starting with ADDR: or BURL: gets parsed as one or the
>> other according to some default that is configurable at the connection,
>> context factory, and JVM levels.
>>
>> --Rafael
>
> Hi Rafi, do you have some examples of your grammar, my cold filled
> head still doesn't follow why you have to start prefixing things.
>
> What ever we do new JNDI, prefixing (which I find a tad strange) we
> need to support both formats simultaneously in a single file to allow
> users to migrate.
If you want to support both formats simultaneously in a single file,
then the only practical way I can think of to do that is with some sort
of meta syntax akin to prefixing. You need some way to clearly and
unambiguously figure out which parser to invoke, both for the sake of
the implementation and for the sake of the people reading the file and
trying to interpret the content.
Please refer to the attached file for an updated the grammar description
with some examples.
--Rafael
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> Your right I probably did but also ment that if you want a Queue
> Object then JNDI InitialContext gives that to you. Currently if you
> actually want the queue to be created on the broker in a pure JMS way
> then createConsumer(..) is the only way to go.
I think we need to support createQueue()/createTopic() for a number of
reasons. First, it is part of the JMS specification, so I don't think we
really have a choice. Second, there are existing usages, and I wouldn't
want to discourage people from using the new format by saying it's not
supported directly via createQueue()/createTopic(). Third, while the JMS
specification does warn that the value passed in is vendor specific, its
arguable that we don't actually care if a user wants to write code that
is specific to a qpid client.
Finally, the actual issue with using it is that destinations are vendor
specific configuration and if you're trying to remain vendor neutral
then you shouldn't hardcode vendor specific configuration into your
applications, however I think there are completely reasonable usages
that don't hardcode configuration, e.g. passing a specification in from
the command line wouldn't make your code at all vendor specific.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Martin Ritchie <ri...@apache.org>.
2009/12/15 Rafael Schloming <ra...@redhat.com>:
> Martin Ritchie wrote:
>>
>> 2009/12/15 Gordon Sim <gs...@redhat.com>:
>>>
>>> On 12/15/2009 08:46 AM, Rafael Schloming wrote:
>>>>
>>>> Gordon Sim wrote:
>>>>>
>>>>> On 12/15/2009 08:07 AM, Rafael Schloming wrote:
>>>>>>
>>>>>> Gordon Sim wrote:
>>>>>>>
>>>>>>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>>>>>>>>
>>>>>>>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>>>>>>>> need to support both formats simultaneously in a single file to
>>>>>>>>> allow
>>>>>>>>> users to migrate.
>>>>>>>>
>>>>>>>> Mixing formats in one file seems unlikely. Wouldn't users change all
>>>>>>>> the urls in their file at once?
>>>>>>>
>>>>>>> That would be my view also.
>>>>>>>
>>>>>>>> Using different context factories for the parsing seems like the
>>>>>>>> best
>>>>>>>> solution to me. It does mean that users have to change code as well
>>>>>>>> as
>>>>>>>> configuration when switching over.
>>>>>>>
>>>>>>> I think they would only need to change code if they were passing
>>>>>>> binding urls to createQueue()/createTopic(). If they were only
>>>>>>> passing
>>>>>>> straight queue names (or topic names) then I don't think any change
>>>>>>> should be necessary to their code. Unless of course I am missing
>>>>>>> something?
>>>>>>
>>>>>> The semantics of createQueue("foo") depend on whether "foo" is
>>>>>> interpreted as an address or not. Under the current semantics this
>>>>>> would
>>>>>> automatically declare the queue on the server. If interpreted as an
>>>>>> address, you would need to supply "foo; {create: always, assert:
>>>>>> always}" in order to get equivalent semantics.
>>>>>
>>>>> Good point. However as long as users get the same semantics if they
>>>>> use the same config file from before (i.e. the old/existing context
>>>>> factory), and as long as we document this subtle shift then I think
>>>>> its acceptable to have any use of createQueue()/createTopic() revised
>>>>> when switching over to the new context factory. (Where JNDI is not
>>>>> used, a flag on the connection that determines whether the value
>>>>> passed in should be treated as a binding url or an address would work).
>>>>
>>>> Are you suggesting that createQueue()/createTopic() behavior would
>>>> somehow be modified by setting the jndi context factory?
>>
>> I don't think this is something we should be doing. If users want to
>> load a JNDI value for createQueue then there are already mechanism for
>> doing that which should be used:
>>
>> createQueue((Queue)initialContext.lookup("foo"));
>
> Unless I'm missing something, there is no createQueue() that takes a Queue.
> Did you mean createConsumer((Queue)...)?
Your right I probably did but also ment that if you want a Queue
Object then JNDI InitialContext gives that to you. Currently if you
actually want the queue to be created on the broker in a pure JMS way
then createConsumer(..) is the only way to go.
Martin
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> 2009/12/15 Gordon Sim <gs...@redhat.com>:
>> On 12/15/2009 08:46 AM, Rafael Schloming wrote:
>>> Gordon Sim wrote:
>>>> On 12/15/2009 08:07 AM, Rafael Schloming wrote:
>>>>> Gordon Sim wrote:
>>>>>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>>>>>>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>>>>>>> need to support both formats simultaneously in a single file to allow
>>>>>>>> users to migrate.
>>>>>>> Mixing formats in one file seems unlikely. Wouldn't users change all
>>>>>>> the urls in their file at once?
>>>>>> That would be my view also.
>>>>>>
>>>>>>> Using different context factories for the parsing seems like the best
>>>>>>> solution to me. It does mean that users have to change code as well as
>>>>>>> configuration when switching over.
>>>>>> I think they would only need to change code if they were passing
>>>>>> binding urls to createQueue()/createTopic(). If they were only passing
>>>>>> straight queue names (or topic names) then I don't think any change
>>>>>> should be necessary to their code. Unless of course I am missing
>>>>>> something?
>>>>> The semantics of createQueue("foo") depend on whether "foo" is
>>>>> interpreted as an address or not. Under the current semantics this would
>>>>> automatically declare the queue on the server. If interpreted as an
>>>>> address, you would need to supply "foo; {create: always, assert:
>>>>> always}" in order to get equivalent semantics.
>>>> Good point. However as long as users get the same semantics if they
>>>> use the same config file from before (i.e. the old/existing context
>>>> factory), and as long as we document this subtle shift then I think
>>>> its acceptable to have any use of createQueue()/createTopic() revised
>>>> when switching over to the new context factory. (Where JNDI is not
>>>> used, a flag on the connection that determines whether the value
>>>> passed in should be treated as a binding url or an address would work).
>>> Are you suggesting that createQueue()/createTopic() behavior would
>>> somehow be modified by setting the jndi context factory?
>
> I don't think this is something we should be doing. If users want to
> load a JNDI value for createQueue then there are already mechanism for
> doing that which should be used:
>
> createQueue((Queue)initialContext.lookup("foo"));
Unless I'm missing something, there is no createQueue() that takes a
Queue. Did you mean createConsumer((Queue)...)?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Martin Ritchie <ri...@apache.org>.
2009/12/15 Gordon Sim <gs...@redhat.com>:
> On 12/15/2009 08:46 AM, Rafael Schloming wrote:
>>
>> Gordon Sim wrote:
>>>
>>> On 12/15/2009 08:07 AM, Rafael Schloming wrote:
>>>>
>>>> Gordon Sim wrote:
>>>>>
>>>>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>>>>>>
>>>>>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>>>>>> need to support both formats simultaneously in a single file to allow
>>>>>>> users to migrate.
>>>>>>
>>>>>> Mixing formats in one file seems unlikely. Wouldn't users change all
>>>>>> the urls in their file at once?
>>>>>
>>>>> That would be my view also.
>>>>>
>>>>>> Using different context factories for the parsing seems like the best
>>>>>> solution to me. It does mean that users have to change code as well as
>>>>>> configuration when switching over.
>>>>>
>>>>> I think they would only need to change code if they were passing
>>>>> binding urls to createQueue()/createTopic(). If they were only passing
>>>>> straight queue names (or topic names) then I don't think any change
>>>>> should be necessary to their code. Unless of course I am missing
>>>>> something?
>>>>
>>>> The semantics of createQueue("foo") depend on whether "foo" is
>>>> interpreted as an address or not. Under the current semantics this would
>>>> automatically declare the queue on the server. If interpreted as an
>>>> address, you would need to supply "foo; {create: always, assert:
>>>> always}" in order to get equivalent semantics.
>>>
>>> Good point. However as long as users get the same semantics if they
>>> use the same config file from before (i.e. the old/existing context
>>> factory), and as long as we document this subtle shift then I think
>>> its acceptable to have any use of createQueue()/createTopic() revised
>>> when switching over to the new context factory. (Where JNDI is not
>>> used, a flag on the connection that determines whether the value
>>> passed in should be treated as a binding url or an address would work).
>>
>> Are you suggesting that createQueue()/createTopic() behavior would
>> somehow be modified by setting the jndi context factory?
I don't think this is something we should be doing. If users want to
load a JNDI value for createQueue then there are already mechanism for
doing that which should be used:
createQueue((Queue)initialContext.lookup("foo"));
> I'm suggesting that the createQueue()/createTopic() behaviour be configured
> through a flag/mode on the connection and that when jndi is used to obtain a
> connection factory the value of that flag/mode could be different based on
> the context factory in use.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> I'm suggesting that the createQueue()/createTopic() behaviour be
> configured through a flag/mode on the connection and that when jndi is
> used to obtain a connection factory the value of that flag/mode could be
> different based on the context factory in use.
Ah, I understand now. That sounds like it would work. I think the
question just boils down to whether we need to support addresses and
binding URLs in use side by side or not (either in the same file or on
the same connection).
It would seem the benefit to not supporting side by side usage is that
we encourage a cleaner switchover, i.e. you go straight from the old to
the new in a single step rather than having to prefix everything until
you've eliminated all occurrences of the old syntax. Whereas supporting
the old and new syntax side by side would allow a more incremental
migration, but would require a second cleanup step at the end when you
have only ADDR prefixed usages remaining.
From an implementation perspective neither option is particularly
onerous. My impulse is probably to lean towards the clean switchover and
not mixing usages, however I believe others have expressed the opposite
view, maybe they could comment on the reasons?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Gordon Sim <gs...@redhat.com>.
On 12/15/2009 08:46 AM, Rafael Schloming wrote:
> Gordon Sim wrote:
>> On 12/15/2009 08:07 AM, Rafael Schloming wrote:
>>> Gordon Sim wrote:
>>>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>>>>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>>>>> need to support both formats simultaneously in a single file to allow
>>>>>> users to migrate.
>>>>>
>>>>> Mixing formats in one file seems unlikely. Wouldn't users change all
>>>>> the urls in their file at once?
>>>>
>>>> That would be my view also.
>>>>
>>>>> Using different context factories for the parsing seems like the best
>>>>> solution to me. It does mean that users have to change code as well as
>>>>> configuration when switching over.
>>>>
>>>> I think they would only need to change code if they were passing
>>>> binding urls to createQueue()/createTopic(). If they were only passing
>>>> straight queue names (or topic names) then I don't think any change
>>>> should be necessary to their code. Unless of course I am missing
>>>> something?
>>>
>>> The semantics of createQueue("foo") depend on whether "foo" is
>>> interpreted as an address or not. Under the current semantics this would
>>> automatically declare the queue on the server. If interpreted as an
>>> address, you would need to supply "foo; {create: always, assert:
>>> always}" in order to get equivalent semantics.
>>
>> Good point. However as long as users get the same semantics if they
>> use the same config file from before (i.e. the old/existing context
>> factory), and as long as we document this subtle shift then I think
>> its acceptable to have any use of createQueue()/createTopic() revised
>> when switching over to the new context factory. (Where JNDI is not
>> used, a flag on the connection that determines whether the value
>> passed in should be treated as a binding url or an address would work).
>
> Are you suggesting that createQueue()/createTopic() behavior would
> somehow be modified by setting the jndi context factory?
I'm suggesting that the createQueue()/createTopic() behaviour be
configured through a flag/mode on the connection and that when jndi is
used to obtain a connection factory the value of that flag/mode could be
different based on the context factory in use.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 12/15/2009 08:07 AM, Rafael Schloming wrote:
>> Gordon Sim wrote:
>>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>>>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>>>> wrote:
>>>>
>>>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>>>> need to support both formats simultaneously in a single file to allow
>>>>> users to migrate.
>>>>
>>>> Mixing formats in one file seems unlikely. Wouldn't users change all
>>>> the urls in their file at once?
>>>
>>> That would be my view also.
>>>
>>>> Using different context factories for the parsing seems like the best
>>>> solution to me. It does mean that users have to change code as well as
>>>> configuration when switching over.
>>>
>>> I think they would only need to change code if they were passing
>>> binding urls to createQueue()/createTopic(). If they were only passing
>>> straight queue names (or topic names) then I don't think any change
>>> should be necessary to their code. Unless of course I am missing
>>> something?
>>
>> The semantics of createQueue("foo") depend on whether "foo" is
>> interpreted as an address or not. Under the current semantics this would
>> automatically declare the queue on the server. If interpreted as an
>> address, you would need to supply "foo; {create: always, assert:
>> always}" in order to get equivalent semantics.
>
> Good point. However as long as users get the same semantics if they use
> the same config file from before (i.e. the old/existing context
> factory), and as long as we document this subtle shift then I think its
> acceptable to have any use of createQueue()/createTopic() revised when
> switching over to the new context factory. (Where JNDI is not used, a
> flag on the connection that determines whether the value passed in
> should be treated as a binding url or an address would work).
Are you suggesting that createQueue()/createTopic() behavior would
somehow be modified by setting the jndi context factory?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Gordon Sim <gs...@redhat.com>.
On 12/15/2009 08:07 AM, Rafael Schloming wrote:
> Gordon Sim wrote:
>> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>>> wrote:
>>>
>>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>>> need to support both formats simultaneously in a single file to allow
>>>> users to migrate.
>>>
>>> Mixing formats in one file seems unlikely. Wouldn't users change all
>>> the urls in their file at once?
>>
>> That would be my view also.
>>
>>> Using different context factories for the parsing seems like the best
>>> solution to me. It does mean that users have to change code as well as
>>> configuration when switching over.
>>
>> I think they would only need to change code if they were passing
>> binding urls to createQueue()/createTopic(). If they were only passing
>> straight queue names (or topic names) then I don't think any change
>> should be necessary to their code. Unless of course I am missing
>> something?
>
> The semantics of createQueue("foo") depend on whether "foo" is
> interpreted as an address or not. Under the current semantics this would
> automatically declare the queue on the server. If interpreted as an
> address, you would need to supply "foo; {create: always, assert:
> always}" in order to get equivalent semantics.
Good point. However as long as users get the same semantics if they use
the same config file from before (i.e. the old/existing context
factory), and as long as we document this subtle shift then I think its
acceptable to have any use of createQueue()/createTopic() revised when
switching over to the new context factory. (Where JNDI is not used, a
flag on the connection that determines whether the value passed in
should be treated as a binding url or an address would work).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 12/15/2009 12:03 AM, Aidan Skinner wrote:
>> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org>
>> wrote:
>>
>>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>>> need to support both formats simultaneously in a single file to allow
>>> users to migrate.
>>
>> Mixing formats in one file seems unlikely. Wouldn't users change all
>> the urls in their file at once?
>
> That would be my view also.
>
>> Using different context factories for the parsing seems like the best
>> solution to me. It does mean that users have to change code as well as
>> configuration when switching over.
>
> I think they would only need to change code if they were passing binding
> urls to createQueue()/createTopic(). If they were only passing straight
> queue names (or topic names) then I don't think any change should be
> necessary to their code. Unless of course I am missing something?
The semantics of createQueue("foo") depend on whether "foo" is
interpreted as an address or not. Under the current semantics this would
automatically declare the queue on the server. If interpreted as an
address, you would need to supply "foo; {create: always, assert:
always}" in order to get equivalent semantics.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Gordon Sim <gs...@redhat.com>.
On 12/15/2009 12:03 AM, Aidan Skinner wrote:
> On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie<ri...@apache.org> wrote:
>
>> What ever we do new JNDI, prefixing (which I find a tad strange) we
>> need to support both formats simultaneously in a single file to allow
>> users to migrate.
>
> Mixing formats in one file seems unlikely. Wouldn't users change all
> the urls in their file at once?
That would be my view also.
> Using different context factories for the parsing seems like the best
> solution to me. It does mean that users have to change code as well as
> configuration when switching over.
I think they would only need to change code if they were passing binding
urls to createQueue()/createTopic(). If they were only passing straight
queue names (or topic names) then I don't think any change should be
necessary to their code. Unless of course I am missing something?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Aidan Skinner <ai...@gmail.com>.
On Fri, Dec 11, 2009 at 9:20 AM, Martin Ritchie <ri...@apache.org> wrote:
> What ever we do new JNDI, prefixing (which I find a tad strange) we
> need to support both formats simultaneously in a single file to allow
> users to migrate.
Mixing formats in one file seems unlikely. Wouldn't users change all
the urls in their file at once?
Using different context factories for the parsing seems like the best
solution to me. It does mean that users have to change code as well as
configuration when switching over.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Martin Ritchie <ri...@apache.org>.
2009/12/10 Rafael Schloming <ra...@redhat.com>:
> Gordon Sim wrote:
>>
>> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>>>
>>> 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.
>>
>> In the case of jndi configuration, what about having a different context
>> factory to do the parsing? I.e. in jndi configuration files using the new
>> syntax you would specify something other than the existing
>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way existing
>> configuration will work as before with no changes, and a new format can be
>> parsed without any need to worry about the older format.
>>
>> That doesn't deal with strings passed to createQueue()/createTopic() of
>> course. Perhaps there a specific 'factory' can be associated with a
>> connection, configured via a connection option? Where a file backed jndi
>> configuration is used the two different context factories could then set
>> different defaults for this meaning again that old config would be
>> unaffected and new config could ignore the old config entirely also.
>>
>> Just a suggestion...
>
> I've been thinking we should just do something like:
>
> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
>
> and anything not starting with ADDR: or BURL: gets parsed as one or the
> other according to some default that is configurable at the connection,
> context factory, and JVM levels.
>
> --Rafael
Hi Rafi, do you have some examples of your grammar, my cold filled
head still doesn't follow why you have to start prefixing things.
What ever we do new JNDI, prefixing (which I find a tad strange) we
need to support both formats simultaneously in a single file to allow
users to migrate.
Martin
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rafael Schloming <ra...@redhat.com>.
Marnie McCormack wrote:
> Hi Rajith,
>
> Thanks.
>
> So if an existing user upgrades, but forgets/doesn't know to change the
> default preifx then they'll get a parsing exception or suchlike back when
> they try to connect ?
We have a choice over what default unprefixed syntax to use. Probably
the most polite thing to do for our current users would be to choose the
old syntax as the default unprefixed syntax, but issue a warning to the
effect that the default will change.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS
client
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Rajith,
Thanks.
So if an existing user upgrades, but forgets/doesn't know to change the
default preifx then they'll get a parsing exception or suchlike back when
they try to connect ?
Marnie
On Mon, Dec 14, 2009 at 8:16 PM, Rajith Attapattu <ra...@gmail.com>wrote:
> On Mon, Dec 14, 2009 at 2:59 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
> > I'm glad to read about plans for supporting both syntaxes going forward,
> and
> > providing backward compatibility.
> >
> > I'm not grasping how prefixing aids migration for existing users (or
> maybe
> > I've misunderstood what the prefix is intended to provide) ? If they have
> to
> > edit/test their connection config then I don't think that'll help.
>
> The prefix is important if people plan to use both the new and old
> format side by side.
> If an entry has no prefix, it will be interpreted according to the
> default prefix (which could be overridden with connection property or
> JVM argument).
>
> For the initial release we should have BURL as the default prefix. So
> existing users will need to do zero config to upgrade.
> For subsequent releases we should change the default prefix to ADDR.
> That way people who use the new format gets the benefit of not having
> to explicitly denote a prefix.
> For existing users they would need to add the prefix or change the
> default prefix.
>
> Regards,
>
> Rajith
>
> > I like Gordon's suggestion as a way of addressing this and allowing
> > migration for users on the old style.
> >
> > Regards,
> > Marnie
> >
> >
> >
> >
> > On Thu, Dec 10, 2009 at 9:39 PM, Rafael Schloming <rafaels@redhat.com
> >wrote:
> >
> >> Gordon Sim wrote:
> >>
> >>> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
> >>>
> >>>> 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.
> >>>>
> >>>
> >>> In the case of jndi configuration, what about having a different
> context
> >>> factory to do the parsing? I.e. in jndi configuration files using the
> new
> >>> syntax you would specify something other than the existing
> >>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way
> existing
> >>> configuration will work as before with no changes, and a new format can
> be
> >>> parsed without any need to worry about the older format.
> >>>
> >>> That doesn't deal with strings passed to createQueue()/createTopic() of
> >>> course. Perhaps there a specific 'factory' can be associated with a
> >>> connection, configured via a connection option? Where a file backed
> jndi
> >>> configuration is used the two different context factories could then
> set
> >>> different defaults for this meaning again that old config would be
> >>> unaffected and new config could ignore the old config entirely also.
> >>>
> >>> Just a suggestion...
> >>>
> >>
> >> I've been thinking we should just do something like:
> >>
> >> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
> >> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
> >>
> >> and anything not starting with ADDR: or BURL: gets parsed as one or the
> >> other according to some default that is configurable at the connection,
> >> context factory, and JVM levels.
> >>
> >> --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
>
>
Re: [java] Adding support for the new address format in the JMS
client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Dec 14, 2009 at 2:59 PM, Marnie McCormack
<ma...@googlemail.com> wrote:
> I'm glad to read about plans for supporting both syntaxes going forward, and
> providing backward compatibility.
>
> I'm not grasping how prefixing aids migration for existing users (or maybe
> I've misunderstood what the prefix is intended to provide) ? If they have to
> edit/test their connection config then I don't think that'll help.
The prefix is important if people plan to use both the new and old
format side by side.
If an entry has no prefix, it will be interpreted according to the
default prefix (which could be overridden with connection property or
JVM argument).
For the initial release we should have BURL as the default prefix. So
existing users will need to do zero config to upgrade.
For subsequent releases we should change the default prefix to ADDR.
That way people who use the new format gets the benefit of not having
to explicitly denote a prefix.
For existing users they would need to add the prefix or change the
default prefix.
Regards,
Rajith
> I like Gordon's suggestion as a way of addressing this and allowing
> migration for users on the old style.
>
> Regards,
> Marnie
>
>
>
>
> On Thu, Dec 10, 2009 at 9:39 PM, Rafael Schloming <ra...@redhat.com>wrote:
>
>> Gordon Sim wrote:
>>
>>> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>>>
>>>> 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.
>>>>
>>>
>>> In the case of jndi configuration, what about having a different context
>>> factory to do the parsing? I.e. in jndi configuration files using the new
>>> syntax you would specify something other than the existing
>>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way existing
>>> configuration will work as before with no changes, and a new format can be
>>> parsed without any need to worry about the older format.
>>>
>>> That doesn't deal with strings passed to createQueue()/createTopic() of
>>> course. Perhaps there a specific 'factory' can be associated with a
>>> connection, configured via a connection option? Where a file backed jndi
>>> configuration is used the two different context factories could then set
>>> different defaults for this meaning again that old config would be
>>> unaffected and new config could ignore the old config entirely also.
>>>
>>> Just a suggestion...
>>>
>>
>> I've been thinking we should just do something like:
>>
>> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
>> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
>>
>> and anything not starting with ADDR: or BURL: gets parsed as one or the
>> other according to some default that is configurable at the connection,
>> context factory, and JVM levels.
>>
>> --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
Re: [java] Adding support for the new address format in the JMS
client
Posted by Marnie McCormack <ma...@googlemail.com>.
I'm glad to read about plans for supporting both syntaxes going forward, and
providing backward compatibility.
I'm not grasping how prefixing aids migration for existing users (or maybe
I've misunderstood what the prefix is intended to provide) ? If they have to
edit/test their connection config then I don't think that'll help.
I like Gordon's suggestion as a way of addressing this and allowing
migration for users on the old style.
Regards,
Marnie
On Thu, Dec 10, 2009 at 9:39 PM, Rafael Schloming <ra...@redhat.com>wrote:
> Gordon Sim wrote:
>
>> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>>
>>> 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.
>>>
>>
>> In the case of jndi configuration, what about having a different context
>> factory to do the parsing? I.e. in jndi configuration files using the new
>> syntax you would specify something other than the existing
>> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way existing
>> configuration will work as before with no changes, and a new format can be
>> parsed without any need to worry about the older format.
>>
>> That doesn't deal with strings passed to createQueue()/createTopic() of
>> course. Perhaps there a specific 'factory' can be associated with a
>> connection, configured via a connection option? Where a file backed jndi
>> configuration is used the two different context factories could then set
>> different defaults for this meaning again that old config would be
>> unaffected and new config could ignore the old config entirely also.
>>
>> Just a suggestion...
>>
>
> I've been thinking we should just do something like:
>
> "ADDR: ..." gets parsed as an address (after removing the ADDR:)
> "BURL: ..." gets parsed as a binding url (after removing the BURL:)
>
> and anything not starting with ADDR: or BURL: gets parsed as one or the
> other according to some default that is configurable at the connection,
> context factory, and JVM levels.
>
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [java] Adding support for the new address format in the JMS client
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 11/25/2009 11:06 PM, Rafael Schloming wrote:
>> 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.
>
> In the case of jndi configuration, what about having a different context
> factory to do the parsing? I.e. in jndi configuration files using the
> new syntax you would specify something other than the existing
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way
> existing configuration will work as before with no changes, and a new
> format can be parsed without any need to worry about the older format.
>
> That doesn't deal with strings passed to createQueue()/createTopic() of
> course. Perhaps there a specific 'factory' can be associated with a
> connection, configured via a connection option? Where a file backed jndi
> configuration is used the two different context factories could then set
> different defaults for this meaning again that old config would be
> unaffected and new config could ignore the old config entirely also.
>
> Just a suggestion...
I've been thinking we should just do something like:
"ADDR: ..." gets parsed as an address (after removing the ADDR:)
"BURL: ..." gets parsed as a binding url (after removing the BURL:)
and anything not starting with ADDR: or BURL: gets parsed as one or the
other according to some default that is configurable at the connection,
context factory, and JVM levels.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS client
Posted by Gordon Sim <gs...@redhat.com>.
On 11/25/2009 11:06 PM, Rafael Schloming wrote:
> 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.
In the case of jndi configuration, what about having a different context
factory to do the parsing? I.e. in jndi configuration files using the
new syntax you would specify something other than the existing
org.apache.qpid.jndi.PropertiesFileInitialContextFactory. That way
existing configuration will work as before with no changes, and a new
format can be parsed without any need to worry about the older format.
That doesn't deal with strings passed to createQueue()/createTopic() of
course. Perhaps there a specific 'factory' can be associated with a
connection, configured via a connection option? Where a file backed jndi
configuration is used the two different context factories could then set
different defaults for this meaning again that old config would be
unaffected and new config could ignore the old config entirely also.
Just a suggestion...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [java] Adding support for the new address format in the JMS client
Posted by Rafael Schloming <ra...@redhat.com>.
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