qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject Re: [java] Adding support for the new address format in the JMS client
Date Tue, 15 Dec 2009 09:22:55 GMT
2009/12/11 Rafael Schloming <rafaels@redhat.com>:
> Martin Ritchie wrote:
>>
>> 2009/12/10 Rafael Schloming <rafaels@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


Mime
View raw message