qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Date Wed, 18 Jan 2017 12:56:47 GMT
On 18/01/17 11:49, Robbie Gemmell wrote:
> On 18 January 2017 at 10:45, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
>> In terms of sending maps/lists I think we said (at OASIS), though it is
>> possibly not yet in the draft spec, that Json formatted equivalents should
>> be able to be used for all values... however I have no idea if the Dispatch
>> Router supports that.
> To be clear, the above is in regard to the AMQP Management spec. I'll
> assume for now that Dispatch does not support a Json encoding.

Correct it does not (and the draft of the spec I linked to does not 
mention it either, not sure if there is a later draft that does).

> Assuming that is the case, and that it won't quickly do so, the main
> issue currently would be sending AMQP encoded maps and lists from the
> JMS client to satisfy the content of the AMQP management messages the
> router expects. While the clients MapMessages do use an AMQP encoded
> map for its content, there are restrictions on its content in line
> with the JMS spec, restrictions which I think the AMQP management spec
> goes beyond.

Actually, for at least some uses, this would probably be enough. A 
CREATE message takes a map as the body, specifying the attribute values. 
Provided these were all simple types - which for the router all would be 
except for policy related attributes - you might be ok. A DELETE body is 
an empty map which should be no problem. A QUERY can take a map with a 
single entry with key attributeNames and a value of a list of names. 
That would I think violate the JMS MapMessage restrictions. However you 
can just leave the body as an empty map and get all the attributes back.

> As Gordon mentioned, there is currently some undocumented
> functionality in the client which would allow it to send more
> generalised maps/lists encoded using the AMQP type system. If you set
> the "JMS_AMQP_TYPED_ENCODING" boolean property to true on the clients
> ObjectMessage (preferably before setting the Serializable body object)
> its content will be encoded using the AMQP type system when sent
> rather than as the output from an ObjectOutputStream as they normally
> would be. Obligatory warning: this remains undocumented for good
> reason, being incomplete and subject to change, though whats there
> currently should work for Maps/Lists as needed here.
>> In terms of receiving lists / maps I would assume that treating the
>> received JMS Message as an ObjectMessage and casting that result to the
>> correct type (List or Map as appropriate) will always work?  Though I
>> should probably wait for Robbie to step in on this one :-)
> Yes, the received messages would be expected to turn up as
> ObjectMessage in this case, and then you would need to treat the
> content appropriately as e.g a Map/List.

Ok, so in that case I should correct my original response and say that a 
reasonable amount of management of the router *could* most likely be 
achieved using JMS at present. No one has done so yet though, as far as 
I'm aware.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message