On 18/01/17 11:49, Robbie Gemmell wrote:
On 18 January 2017 at 10:45, Rob Godfrey <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
