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 2010/01/08 23:56:49 UTC
Consistent naming convention for JMS client properties (and possibly
other clients)
Hi All,
The JMS client does not have a consistent naming convention for system
properties, connection URL properties or extension properties
specified in extra arguments sent in AMQP commands.
Some properties start with "amqj[dot]" while other start with
"qpid[dot]" and some without any sort of prefix.
This has led to confusion and sometimes two different properties exist
for configuring the same parameter.
We also don't have a single place within the code or within
documentation that lists all these properties.
Therefore I propose the following.
1. Name all configuration properties, extension properties and
connection URL properties starting with "qpid[dot]"
The c++ client is also following the same strategy. It would be
great if the rest of the clients follow a similar naming convention as
well.
2. We should provide backwards compatibility for the currently
supported properties with a warning that it will be discontinued after
two release cycles.
3. For JMS/Java we could use the ClientProperties.java as a
place-holder for defining the property names. A similar place should
exist for the broker side.
4. Document all properties in one single place
I plan to add this in the new svn documentation that jonathan is
putting together.
A preliminary version could be added in the wiki.
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: Consistent naming convention for JMS client properties (and
possibly other clients)
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Jan 11, 2010 at 8:55 AM, Robert Godfrey <ro...@gmail.com> wrote:
> 2010/1/8 Rajith Attapattu <ra...@gmail.com>
>
>> Hi All,
>>
>> The JMS client does not have a consistent naming convention for system
>> properties, connection URL properties or extension properties
>> specified in extra arguments sent in AMQP commands.
>> Some properties start with "amqj[dot]" while other start with
>> "qpid[dot]" and some without any sort of prefix.
>> This has led to confusion and sometimes two different properties exist
>> for configuring the same parameter.
>> We also don't have a single place within the code or within
>> documentation that lists all these properties.
>>
>> Therefore I propose the following.
>>
>> 1. Name all configuration properties, extension properties and
>> connection URL properties starting with "qpid[dot]"
>> The c++ client is also following the same strategy. It would be
>> great if the rest of the clients follow a similar naming convention as
>> well.
>>
>>
> agreed with this for all properties where there is not some explicit AMQP
> extension convention (e.g. x- )
Agreed.
>
>> 2. We should provide backwards compatibility for the currently
>> supported properties with a warning that it will be discontinued after
>> two release cycles.
>>
>> 3. For JMS/Java we could use the ClientProperties.java as a
>> place-holder for defining the property names. A similar place should
>> exist for the broker side.
>>
>>
> Maybe... Having a class which is just a set of Strings never feels very
> appealing to me. Certainly every constant should be defined once and only
> once though..
I understand your point. But as you also pointed out, the motivation
behind this is to ensure a single place where we have all the
definitions rather than all over the place.
I am thinking about adding some support to the ClientProperties class
to handle the backwards compatibility ..etc.
I intend to post a patch for this.
>
>> 4. Document all properties in one single place
>> I plan to add this in the new svn documentation that jonathan is
>> putting together.
>> A preliminary version could be added in the wiki.
>>
>>
> Sort of related, this is where I started documenting the extensions to AMQP:
>
> http://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP
>
> Where we start talking about client options I think we need to be very
> careful about defining *what* they are options to... i.e. do they alter only
> client internal behaviour... or are they something that is passed down the
> wire to the broker... etc...
Excellent point !!
>
> -- Rob
>
>> 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
>>
>>
>
--
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: Consistent naming convention for JMS client properties (and
possibly other clients)
Posted by Robert Godfrey <ro...@gmail.com>.
2010/1/8 Rajith Attapattu <ra...@gmail.com>
> Hi All,
>
> The JMS client does not have a consistent naming convention for system
> properties, connection URL properties or extension properties
> specified in extra arguments sent in AMQP commands.
> Some properties start with "amqj[dot]" while other start with
> "qpid[dot]" and some without any sort of prefix.
> This has led to confusion and sometimes two different properties exist
> for configuring the same parameter.
> We also don't have a single place within the code or within
> documentation that lists all these properties.
>
> Therefore I propose the following.
>
> 1. Name all configuration properties, extension properties and
> connection URL properties starting with "qpid[dot]"
> The c++ client is also following the same strategy. It would be
> great if the rest of the clients follow a similar naming convention as
> well.
>
>
agreed with this for all properties where there is not some explicit AMQP
extension convention (e.g. x- )
> 2. We should provide backwards compatibility for the currently
> supported properties with a warning that it will be discontinued after
> two release cycles.
>
> 3. For JMS/Java we could use the ClientProperties.java as a
> place-holder for defining the property names. A similar place should
> exist for the broker side.
>
>
Maybe... Having a class which is just a set of Strings never feels very
appealing to me. Certainly every constant should be defined once and only
once though...
> 4. Document all properties in one single place
> I plan to add this in the new svn documentation that jonathan is
> putting together.
> A preliminary version could be added in the wiki.
>
>
Sort of related, this is where I started documenting the extensions to AMQP:
http://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP
Where we start talking about client options I think we need to be very
careful about defining *what* they are options to... i.e. do they alter only
client internal behaviour... or are they something that is passed down the
wire to the broker... etc...
-- Rob
> 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
>
>