qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Fwd: Re: Java QMF console classes in org.apache.qpid.console seem very broken!!
Date Mon, 13 Jun 2011 11:30:31 GMT
On 06/10/2011 06:42 PM, Ted Ross wrote:
> One of the main differences in QMFv2 is that the messages use the
> map/list encodings which make the contents much more user friendly. As
> such, the functionality of qpid-config could readily be implemented
> using just the JMS messaging interface (or any other language interface)
> without need for special libraries.

There are two issues that make QMFv2 awkward from JMS.

The first is simple to fix but can't be done external to the library, 
and that is that there appears to be no way to set the AMQP 0-10 
specific app-id field on a message which the brokers QMFv2 
implementation currently requires.

I'd suggest we follow the approach taken by the python and c++ clients 
and allow AMQP specific fields to be accessed via a specially named 
custom property as in the attached patch. I've raised a JIRA to track 
this: https://issues.apache.org/jira/browse/QPID-3302. I'd also quite 
like to relax the implementation on the broker to not force this.

The second is that the format of response to queries is an AMQP encoded 
list message. There is no built in support for that in the current JMS 
client. You can of course do the decode externally, but it would be nice 
to get the library to do that for you, perhaps exposing it as a 

I've raised https://issues.apache.org/jira/browse/QPID-3303 to track 
that. Again, ideally the protocol used for management would also evolve 
to allow map messages to be sufficient (e.g. some property in the query 
that indicates acceptable response formats).

> I'll see if I can dig up the
> documentation for the message formats for the broker.

I think the best resource currently available is 
https://cwiki.apache.org/qpid/qmf-map-message-protocol.html, that's a 
reasonably good starting point but it's not complete.

View raw message