You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rob Godfrey (Created) (JIRA)" <ji...@apache.org> on 2012/04/16 10:42:46 UTC
[jira] [Created] (QPID-3949) [Java AMQP 1.0] Update JMS Filter
implementations to use new proposed descriptors
[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
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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 filter proposals
Posted by Gordon Sim <gs...@redhat.com>.
On 04/27/2012 10:15 AM, Gordon Sim wrote:
> I've put up a minor revision to the proposal on review board for anyone
> interested:
>
> https://reviews.apache.org/r/4913/
>
> This is essentially Rob's first proposal with a modification of the JMS
> filters to make them more easily applicable to other clients. It also
> drops the requirement for multiple bindings to legacy exchanges at this
> point - and hence the or (and other boolean) combinators - as we lack
> consensus on the solution to that at present and don't want to derail
> meeting the primary requirements.
>
> The intention is for both brokers and all clients to support these
> filters and indeed to have the filters registered with OASIS (under the
> apache.org namespace) for anyone else who is interested in supporting
> the same functionality.
>
> Comments welcome!
I've committed the patch above and would like to proceed to request
OASIS to register these filters. Any last minute objections?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 filter proposals
Posted by Gordon Sim <gs...@redhat.com>.
I've put up a minor revision to the proposal on review board for anyone
interested:
https://reviews.apache.org/r/4913/
This is essentially Rob's first proposal with a modification of the JMS
filters to make them more easily applicable to other clients. It also
drops the requirement for multiple bindings to legacy exchanges at this
point - and hence the or (and other boolean) combinators - as we lack
consensus on the solution to that at present and don't want to derail
meeting the primary requirements.
The intention is for both brokers and all clients to support these
filters and indeed to have the filters registered with OASIS (under the
apache.org namespace) for anyone else who is interested in supporting
the same functionality.
Comments welcome!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 filter proposals
Posted by Gordon Sim <gs...@redhat.com>.
On 04/16/2012 11:24 AM, Rob Godfrey wrote:
> On 16 April 2012 12:03, Gordon Sim<gs...@redhat.com> 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...
The message properties themselves are 'translated' into the AMQP 1.0
equivalents and then back again when transferring the message.
Translating the filter string for that same mapping seems reasonable to me.
It doesn't seem particularly arduous either (unless I'm missing
something); its just replacing one name with another.
> 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.
I'd like a selector that makes sense to use from other clients. Ideally
I'd like the underlying filter to be the same for such cases whether
sent by a JMS client or any other.
Forcing all components to adopt JMS naming seems (even) less desirable
than having the JMS components translate to a more AMQP friendly naming
scheme.
>> 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.
That certainly seems a useful, pragmatic approach for a JMS client
*implementation* such as Qpid. It seems a little weak as a standard JMS
mapping however, though clearly that point is for another list.
(In passing, such a function would make translating to AMQP names in
place of JMS names in the selector even less arduous).
>> (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).
Point taken in general, but given you can define multiple filters for a
given link (i.e. combine in the 'AND' sense) are there more concrete
use-cases at present?
I'm keen for registered extensions not to get too far ahead of
implementations. Adding is generally easier than removing or modifying.
A limited set of filters with wide support is better than a wider range
of filters each with limited support.
>> 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.
I see it quite differently.
The goal appears to me to be tactical and specific: defining filters
that correspond to the routing behaviour defined for the standard
exchange types in previous incarnations of the specification so that
implementations (such as Qpid) based on those can support pub-sub
patterns by exposing exchanges as nodes supporting the appropriate
filter type.
Within this scope, the question is whether to support multiple bindings
from the same exchange for a given subscriber, and if so how best to do
that.
One approach, which I am suggesting, covers this through a minimal
change to the legacy filter definitions.
Another approach, as proposed by you, is to expand the scope to a more
general filtering solution, adding general purpose boolean operators.
I feel this goes further than is needed for a tactical solution while
not going far enough for a strategic solution. I feel the requirements
for the general solution are still too vague.
I am not suggesting adding an alternative way; I am suggesting keeping a
more limited scope for the tactical solution to the immediate goals.
The code for existing exchange implementations is going to be distinct
from any more general purpose implementation in the future anyway.
> 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.
Expressing filtering capabilities of a node is more complex in the
proposed approach; you need to define not simply what filters are
supported but the valid ways in which they can be assembled.
If the goal is exposing the standard exchange types in 1.0 that seems
less desirable to me. It seems more likely to lead to a situation where
implementation specific, under-specified combinations of the primitives
emerge in an ad-hoc fashion.
Of course we don't want to rule out use cases for no reason, but this
case, as a Qpid specific extension, is at least different in scope.
I'd also suspect it is of much narrower applicability.
You could still have binding-key AND selector - through two separate
filters on the source - which would cover what I understand to be the
motivating use case for that feature i.e. a selector on a topic consumer
in JMS.
The only cases not covered are where you want to combine multiple such
pairs. If there is a real need for that, I'd rather see it defined as a
special legacy filter of its own.
>> 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"
Is there a reason for that? Having the parsing done on the broker seems
somewhat simpler to me on the face of it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 filter proposals
Posted by Rob Godfrey <ro...@gmail.com>.
On 16 April 2012 12:03, Gordon Sim <gs...@redhat.com> 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: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
AMQP 1.0 filter proposals
Posted by Gordon Sim <gs...@redhat.com>.
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
> 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
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.
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?
(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.
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.
Given the JMS style selector filter, what would be the use case for the
more generic combinators beyond simple 'or' lists for legacy exchanges?
[I spotted a minor typo in the first paragraph of section 3: "a
primitive notion of combing filters", should be 'combining'].
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Resolved] (QPID-3949) [Java AMQP 1.0] Update JMS Filter
implementations to use new proposed descriptors
Posted by "Rob Godfrey (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey resolved QPID-3949.
-------------------------------
Resolution: Fixed
> [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
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org