You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2009/12/10 18:14:04 UTC
Re: [java] Adding support for the new address format in the JMS client
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>.
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