On 16 February 2014 09:25, Fraser Adams <fraser.ad...@blueyonder.co.uk>wrote:
> On 15/02/14 21:11, Robbie Gemmell wrote:
>
>> On 14 February 2014 09:20, Fraser Adams <fraser.ad...@blueyonder.co.uk
>> >wrote:
>>
>> The message reported by drain says:
>>>
>>> Message(properties={spout-id:88fc4a67-d71e-4b86-b967-f897306400e7:0},
>>> subject='tim', content='Hello World')
>>>
>>> So *something* thinks that there's a subject property set, but the
>>> selector doesn't seem to see it.
>>>
>>>
>>> I expect that means the 'subject' field of the 'properties' section of
>> the
>> AMQP message is set, and not a 'property' called 'subject' in the
>> 'application-properties' section (which is where the spout-id property is
>> presumably being set).
>>
> Thanks Robbie, yeah this had started to dawn on me yesterday. I was
> looking through the C++ broker code and noticed in
> <qpid>/cpp/src/qpid/broker/amqp/Message.cpp
>
> std::string Message::getRoutingKey() const
> {
> std::string v;
> v.assign(subject.data, subject.size);
> return v;
> }
>
> which seems to be the only place where subject gets exposed - so it's in a
> specific accessor not a general property one, then I remembered that AMQP
> 1.0 has immutable properties in section 3.2.4 and application properties in
> 3.2.5 and remembered that subject is one of the 3.2.4 properties.
>
> in <qpid>/qpid-trunk/qpid/specs/apache-filters.xml it explains about
> mapping the JMS headers and most of the JMS headers relate to 3.2.4
> properties.
>
> What I think is happening is that in AMQP 1.0 qpid::messaging used by
> spout actually populates the AMQP 1.0 subject field correctly with the
> subject, but when specifying subject in the Selector that's looking for an
> *application property* called "subject". That'll be why the AMQP 0.10 thing
> works because the legacy "qpid.subject" actually *is* an application
> property.
>
> In <qpid>/cpp/src/qpid/broker/Selector.cpp there's a method:
> const Value MessageSelectorEnv::specialValue(const string& id) const
>
> That does the mappings mentioned in the apache-filters.xml
>
> the method
>
> const Value& MessageSelectorEnv::value(const string& identifier) const
>
> Checks for the prefix "amqp." and if set calls specialValue() otherwise it
> looks up the application properties.
>
> Of the AMQP 1.0 section 3.2.4 properties it looks like
> user-id
> to
> subject
> reply-to
> content-type
> content-encoding
> group-id
> group-sequence
> reply-to-group-id
>
> Don't have any accessor in the Selector (though to and reply-to have a
> comment "Hard to get this correct for both 1.0 and 0-10" though it might be
> worth exposing them as a LIKE operator might help abstract the differences)
> the group-id, group-sequence and reply-to-group-id don't even appear to be
> extracted in Message.cpp from what I can see.
>
> Anyway I'd *imagine* that it wouldn't be terribly hard to expand the
> pattern used for the JMS Headers to allow access to some of these e.g.
> Selector keys of
> amqp.user_id
> amqp.subject
> amqp.content_type
> amqp.content_encoding
>
> Would make them visible to specialValue() where they could be added to the
> if/else block and their specific accessors could then be called.
>
> I don't know if there is any specific reason for not doing this other than
> the original goal being to map JMS Message Selectors.
>
> From my responses to Clive it would seem to suggest that subject at least
> would be really useful to be exposed to a Selector especially as it's a
> core routing attribute for other filter types.
>
> I'd be interested to know what others think - it looks a fairly simple
> addition.
>
>
>
>>
>> Does anybody know how to specify the message subject as a property for a
>>> Message Selector in AMQP 1.0???
>>>
>>> As the filter in question is specifically only covering functionality
>> required for JMS (specifically mapping the JMS Headers to the relevant
>> fields in the AMQP headers and properties sections, and JMS properties to
>> the AMQP application-properties section) its not clear to me that it
>> allows
>> for selection of the 'subject' field in the 'properties' section, because
>> that isn't used to map any of the JMS headers or property values and so
>> effectively isn't discussed.
>>
>> [snip]
>>
> Yeah as mentioned above that looks about right. I've not looked in the
> Java Broker Selector code, but I imagine that it does something similar to
> the C++ code and looks for the "amqp." prefix but only covers the 3.2.4
> properties mentioned in apache-filters.xml.
>
I wouldnt necessarily assume it supports this filter yet...
>
> To my mind it doesn't seem unreasonable to extend this to subject (at
> least) given that it's a key filtering property for other filters, but it's
> probably worth a discussion.
>
This basically goes back to the earlier discussion in that there are things
the filter can't do, because it didn't (and still doesn't) need to for the
reason it was explicitly created. It may be worth either generalising it to
support more stuff like this or adding another filter that does.
>
> Cheers,
> Frase
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
