Page History

...

Candidates: Lahiru Gunathilaka, Ruchira Wageesha

Project Goal: Provide the ability to access Java Broker mgmt info from cmd line.

...

Design and implement a simple solution, runnable from the command line, for extracting useful JMX information from the Qpid Java Broker. Solution should be configurable at runtime to allow users to decide which bits of info they're interested in and when. Might be nice to see the information extracted in a report format

More info:

Currently, the Qpid Java broker provides several JMX methods to all users/applications to extract information about queues etc on the broker. We have used this information for two purposes: exposing management details in the existing Eclipse RCP Management Console UI and also to provide alerting in the broker log when certain configurable thresholds are reached e.g. maximum queue size etc.

However, some of our users have expressed an interest in being able to extract JMX information more simply i.e. without the constraints our existing confgurable alerting brings with it and also independently of the UI.

Thus, an application which could be called from the command line on Windows, Unix (Solaris) and Linux would be invaluable for our user projects.

Ideally this CLI would expose all the JMX calls in a simple wrapper and perhaps allow the user to dump the results to an XML file or a web page.

This is not intended to be too heavily prescriptive and is really intended as a starter for ten !

Qpid-java-broker-config

Candidates: Sachith Danushka.

...

Refactor Qpid Java Broker configuration into a more elegant xml schema, with xsd, covering all existing configuration options and allowing for extension. Additionally implement a module to validate broker configuration files, which could be run standalone i.e. before starting a broker, to check that they're well formed and validate against the xsd.

More info:

Currently the broker configuration for the Qpid Java Broker is a little untidy. There's the bulk of the core broker configuration, much of which the majority of our end users won't want to change much, in the default config.xml files that we ship. On top of that we have a set of properties for the virtualhosts (which includes the ability to define per host some queues which will always exist on broker startup etc) in a separate file.

At the moment, if you edit the config.xml file you're using and accidentally damage or remove an important section the broker will blow up in an unexpected fashion. Creating an xsd and validating the config.xml at startup (probably as a switch on/off-able option !) would help to avoid this possibility.

We could also provide more information about what the config file contains in a self-documenting way. I'd suggest we need to restructure the config set up too - the virtualhosts file is at the very least badly named, but probably not really fit for purpose.

qpid-android-demo

Project Goal:
Implement a simple demo on Android using the Qpid client to send messages to and from a broker, such as stock price information and trade orders

...