On Thu, 13 Jan 2011, Andrew Kennedy wrote:
I would suggest a nice pluggable architecture. There would be a broker info
provider class, just like you suggested, which would be feeding into a one or
many publisheres. These could be, for example:
* A '/var/lib/qpid/' filesystem driver on Linux
* A 'C:\Documents and Settings\Qpid User\Local Settings\Application Data\'
filesystem driver for Windows
* A Registry driver on Windows
* An Active Directory driver on Windows Server
* an SNMP MIB generator for systems with an SNMP agent
* A JMX driver on the Java broker
* A QMF driver for both Java and C++ brokers
You could include a lot of information in the provider's dump and the
publisher plugins will decide what information to filter out of this and
select and how (and how often) to present it.
I think this is a different proposal to Mick's.
Yours is about adding indirection for the broker's internal mgmt event
system, so you could for instance get a bunch of log output for mgmt
events, or you could get them published as qmf events.
To my impression, Mick's is much smaller. It's about a simple way to
discover some basic info (and I'd argue it's strictly runtime configuration).
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
