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: [email protected]
For additional commands, e-mail: [email protected]
