On 16 April 2012 12:03, Gordon Sim <[email protected]> wrote:
> On 04/16/2012 09:42 AM, Rob Godfrey (Created) (JIRA) wrote:
>
>> [Java AMQP 1.0] Update JMS Filter implementations to use new proposed
>> descriptors
>> ------------------------------**------------------------------**
>> ---------------------
>>
>> Key: QPID-3949
>> URL:
>> https://issues.apache.org/**jira/browse/QPID-3949<https://issues.apache.org/jira/browse/QPID-3949>
>> Project: Qpid
>> Issue Type: Bug
>> Components: Java Broker, Java Client
>> Affects Versions: 0.17
>> Reporter: Rob Godfrey
>> Assignee: Rob Godfrey
>> Fix For: 0.17
>>
>>
>> Update the Java AMQP 1.0 implementation to use the filter descriptors
>> defined here:
>>
>> http://people.apache.org/~**rgodfrey/amqp-1.0/apache-**filters.xml<http://people.apache.org/%7Ergodfrey/amqp-1.0/apache-filters.xml>
>>
>
> Couple of comments on this proposal:
>
> (1) It seems like translating from JMS property names to something more
> generally applicable in AMQP in the JMS client would be from some
> perspectives at least most 'natural'. That way the knowledge of JMS names
> remains in the component directly concerned with implementing that
> specification. It could be as simple as a string replacement of JMS name by
> field name of corresponding AMQP 1.0 field name.
>
> In this case the name of the filter could also be made a little more
> generic. Likewise as specified there is no need to have 'jms' in the name
> of the no-local filter as it is useful and supported for other use cases as
> well.
>
>
The main driver here is that for people implementing AMQP 1.0 over an
existing JMS implementation they do not wish to have to translate the
filters from JMS to AMQP and then back again... For pure AMQP 1.0
implementations such as Qpid this obviously seems less natural. I think
there is a good case to be made that we should define an SQL like query
syntax which allows evaluation of all properties and annotations of an AMQP
1-0 message, however I think that is a separate task.
> While I can see the desire to have a single capability for the two filters
> driven by JMS, there is also a view that tying them together is not
> necessary. You could support no-local but not the full selector filter.
> Perhaps we could have distinct capabilities for the filters and then have a
> more all-encompassing capability for a more complete JMS mapping?
>
>
For the final JMS mapping I think that the most likely way forward is to
specify that a server may offer one of a number of different filter types
that have the expressive power as JMS filters, and that clients must be
capable of using which filter syntax (from the approved list) the server
supports. Discussions amongst the AMQP implementers have never been able
to agree a single syntax that all can agree on based upon the different
histories of their products. Putting the burden on the client is somewhat
easier as we can produce an Apache licensed open source conversion function
that given a JMS selector string will compile the necessary AMQP 1.0 filter
expression. Since JMS clients must (by definition) be written in Java at
some level this should be enough for anyone writing a JMS client.
> (2) I am leaning to the view that allowing lists in the 'legacy AMQP
> exchange binding' filters would be a simpler and more direct expression of
> the legacy support than the generic and/or/not combinators.
>
>
The and/or/not expressions will be required anyway and as such I am keen to
add them now. The idea is generally that you should be able to combine
different sorts of filters which may be very specific and not expressible
easily in terms of property values (like no-local).
> Without modifying the actual capabilities of the different exchange types,
> only the 'or' would be valid and even in that case the actual list would
> need to consist only of the filters valid for the exchange type. For the
> topic and direct exchanges a list of keys gives - in my view - a more
> obvious indication of the actual capability.
>
>
As above I think the logical operations are a necessary set of filters, I'm
reluctant to add an alternative way of achieving the same ends for a single
use case. Moreover for the Java Broker you can currently qualify the
binding-key filter with a secondary (JMS) selector in AMQP 0-9 and 0-10, so
that your actual binding is ( binding-key1 AND selector1) OR (binding-key2
AND selector2) OR ... The proposal to just use lists of binding keys would
not allow for this functionality.
> Given the JMS style selector filter, what would be the use case for the
> more generic combinators beyond simple 'or' lists for legacy exchanges?
>
Other implementers are very keen that selectors be specified in terms of an
AST (so a client side selector might be encoded as something like
and(equals(app-property("my-prop"), "my-value"),
less-than(message-annotation("foo-size"), 42)) as opposed to a string
"application-properties.my-prop = 'my-value' and
message.annotation.foo-size < 42"
>
> [I spotted a minor typo in the first paragraph of section 3: "a primitive
> notion of combing filters", should be 'combining'].
>
>
Thanks - will fix that now.
> None of these are major issues of course, but it seems worth a small
> amount of debate before nailing them down and getting them registered.
>
>
Agreed - that is why these are proposals only :-)
-- Rob
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> [email protected].**org<[email protected]>
> For additional commands, e-mail: [email protected]
>
>
