Hi Ruchira,

Firstly, thank you for your interest in our projects !

I can give you a little more information about these two proposals, which
I'll put on our project wiki too. I hope that you find this useful detail:

1. CLI for extracting JMX information from the Qpid Java broker

Described on our submission as:

*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 extrac*
*ted 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 !

2.Qpid Java broker configuration

Described on our submission as:

*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.

Again, I hope this extra detail is helpful.

Regards,
Marnie
Qpid Dev Team

On 3/12/08, Ruchira Wageesha <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I am 3rd year university student at University of Moratuwa, Sri Lanka. I
> am interested to implement one of the projects /*CLI for extracting JMX
> information from the Qpid Java broker ***/or  /*Qpid Java broker
> configuration */for GSOC 2008. I think this project will help me to use
> my knowledge I gathered so far from following areas.
>
> I have a good experience regarding following technologies,
>   Java/JMX/RMI/JMS
>   Web Sevices/ Axis2
>   XML/XML schema
>   WSDL 1.0 and 2.0
>   XSLT/XPath
>   REST
>   WADL
>
> I have developed a tool to generate a WSDL2.0 for the forms at a url.
> This has been hosted at http://ww2.wso2.org:8080/form2wsdl2test/ for
> testing purposes.
>
> If you think I have enough qualifications for this project, can you
> please provide more details about this project. It will be really
> helpful when preparing the proposal.
>
> regards,
> Ruchira Wageesha
>

Reply via email to