You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ruchira Wageesha <ru...@wso2.com> on 2008/03/12 16:08:32 UTC
GSoC 2008-Qpid projects
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
Re: GSoC 2008-Qpid projects
Posted by Rajith Attapattu <ra...@gmail.com>.
Ruchira,
Thank you very much considering the Apache Qpid project.
Have we answered all your questions/concerns regarding the project?
Could you please send an email to the list outlining which project you would
like to take.
There is also another student who has mentioned interest in the
qpid-java-broker-configuration.
Therefore would you like to take up the "CLI for extracting JMX information
from the Qpid Java broker" project?
Regards,
Rajith
Qpid Dev Team.
On Thu, Mar 13, 2008 at 5:12 PM, Marnie McCormack <
marnie.mccormack@googlemail.com> wrote:
> 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 <ru...@wso2.com> 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
> >
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: JMX + MGNT
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi All,
I think Carl's suggestion is a good one, and this area would be a good
opportunity for a new person to get involved.
I'm assuming that we can keep is separate from the existing GSOC projects.
I agree with Robert's comments about keeping the JMX inetrfaces as I do
think they're useful independently, and not very expensive to implement etc.
Regards,
Marnie
On 3/14/08, Robert Greig <ro...@gmail.com> wrote:
>
> On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
> >
> > I like this idea, but I don't want to have to open a WS connection to
> > each broker, I would
> > prefer an architecture where the interface to WS-DM could be off-loaded
> > to anywhere on the network, on the
> > C++ side I would think we would create a WS-DM to AMQP-mgmt bridge. C++
> > uses the
> > following to get info in/out of the broker for mgmt
> > http://cwiki.apache.org/qpid/management-design-notes.html
>
> OK this makes sense. Of course if you use a tool such as WinRM or HP
> Openview or Tivoli then it can present a consolidated view of the
> brokers.
>
> > I also want to make it possible to payload more than just broker mgmt
> > info on the mgnt channel.
>
> Can you give some examples?
>
> > Question, go from AMQP-mgmt to WS-DM or to JMX then to WS-DM? I would
> > think straight to WS-DM but then
> > how would the Java Broker fit in? would we add the AMQP-mgnt to Java
> > broker, map JMX to WS-DM on Java side
> > etc... going to JMX is an easier community project, as many JMX
> > consoles in open source exist, don't know of any OSS
> > WS-DM ones exist
>
> I'm not quite sure of the question? JMX provides an adaptor so that
> you can expose any MBean as WS-M.
>
> If I understand it, you are suggesting a separate process that speaks
> AMQP-Management to brokers but itself is exposed over WS-M. In that
> case, you'd implement the separate process in terms of JMX and it
> would then be able to support native JMX clients and WS-M clients.
>
> Is AMQP management an approved AMQP spec?
>
> I would obviously be interested in the thoughts of other users but in
> terms of priority, I am not convinced that implementing
> AMQP-Management is particularly pressing for the Java broker - there
> are other things our users want that offer more advantages. The reason
> is that the third party management tools do not speak AMQP-Management
> (and almost certainly never will).
>
> As it stands, by doing some testing with the Sun JMX/WS-M adapter we
> can claim out of the box HP OpenView and Microsoft WinRM (and possibly
> Tivoli) interoperability.
>
> We should think about the things we expose over WS-M or SNMP which is
> what the users will interact with (indirectly). Ideally these should
> be consistent across the C++ and Java projects.
>
> > Also, does apache WS have a WS-DM impl (Rajith..?) do you know?
>
> https://wiseman.dev.java.net/ is one.
>
> RG
>
Re: JMX + MGNT
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> sure, as you know qpid get's included into fedora, this feature has been
>> picked up to also
>> transport OS info, CPU, interrupts, network etc.
>>
>> Another project that I know that has picked it up is looking to push
>> data around hypervior info
>>
>> And yet another is doing work laying sec alerts, and resource
>> utilization over the same mechanism. It turns
>> out it is very easy to create another mgmt object and integrate it.
>>
>
> Interesting. This raises some further questions in my mind:
>
> 1) What applications/tools view and process the data? i.e. if a group
> puts CPU info into the management messages, what do they read it in?
>
>
this is what is impl in the C++ broker so far:
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/specs/management-schema.xml
Also, to play with it there is are a few options, easiest is the following
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/python/mgmt-cli/main.py
is an interactive cmd line test tool.
> 2) For some of these it sounds like the message format is being used
> as a general format for management info that is pretty much
> independent of the broker (or Qpid).
yes.
> Is this intended to replace or
> compete with WS-M?
>
>
WS-DM is hell on so many levels, that my view is to only use it for
integration with BMC,
Tivoli etc.
>> not yet ... but multiple parties in AMQP Working Group have expressed
>> support for it, one
>> of the rabbit users has been working with it also - I am sure hit will
>> get updated somehow before
>> making it's way into a release. Discussion so far is in the WG is that
>> it would be optional to impl as part
>> of the spec.
>>
>
> The advantage of this I suppose is that if multiple broker
> implementations supported it, users could manage their installations
> from a single tool. Or, more realistically, if users wrote scripts
> against the JMX interface, those would be portable across different
> brokers.
>
>
yes.
> I think it would be useful to know how concrete the Rabbit (or other
> vendor) plans are.
>
>
time will tell
>> yes agree, thus I was suggesting that it is nice project for someone to
>> pick up, so the
>> bridge exists and then makes it valuable for Java broker when it gets to
>> it. The questions
>> is -- if we do a bridge as a project would that also be interesting for
>> the Java broker down the road?
>>
>
> I think it would be interesting. Even in the short term, it would be
> useful for the C++ and Java brokers to share the management verbs and
> properties. From a user perspective if the bridge supported WS-M and
> JMX then the C++ (via the bridge) and Java brokers (natively) would in
> theory support the same set of tools.
>
>
yes, that is my thinking.
>> yes, there are two places we can map this, at the broker into the
>> AMQP-mgmt protocol or
>> at the impl of the bridge. I think the former is the better approach --
>> please comment if you
>> don't agree
>>
>
> I think that AMQP-mgmt is a better approach if it gets proper buy-in.
>
>
agree.
Carl.
Re: JMX + MGNT
Posted by Robert Greig <ro...@gmail.com>.
On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
> sure, as you know qpid get's included into fedora, this feature has been
> picked up to also
> transport OS info, CPU, interrupts, network etc.
>
> Another project that I know that has picked it up is looking to push
> data around hypervior info
>
> And yet another is doing work laying sec alerts, and resource
> utilization over the same mechanism. It turns
> out it is very easy to create another mgmt object and integrate it.
Interesting. This raises some further questions in my mind:
1) What applications/tools view and process the data? i.e. if a group
puts CPU info into the management messages, what do they read it in?
2) For some of these it sounds like the message format is being used
as a general format for management info that is pretty much
independent of the broker (or Qpid). Is this intended to replace or
compete with WS-M?
> not yet ... but multiple parties in AMQP Working Group have expressed
> support for it, one
> of the rabbit users has been working with it also - I am sure hit will
> get updated somehow before
> making it's way into a release. Discussion so far is in the WG is that
> it would be optional to impl as part
> of the spec.
The advantage of this I suppose is that if multiple broker
implementations supported it, users could manage their installations
from a single tool. Or, more realistically, if users wrote scripts
against the JMX interface, those would be portable across different
brokers.
I think it would be useful to know how concrete the Rabbit (or other
vendor) plans are.
> yes agree, thus I was suggesting that it is nice project for someone to
> pick up, so the
> bridge exists and then makes it valuable for Java broker when it gets to
> it. The questions
> is -- if we do a bridge as a project would that also be interesting for
> the Java broker down the road?
I think it would be interesting. Even in the short term, it would be
useful for the C++ and Java brokers to share the management verbs and
properties. From a user perspective if the bridge supported WS-M and
JMX then the C++ (via the bridge) and Java brokers (natively) would in
theory support the same set of tools.
> yes, there are two places we can map this, at the broker into the
> AMQP-mgmt protocol or
> at the impl of the bridge. I think the former is the better approach --
> please comment if you
> don't agree
I think that AMQP-mgmt is a better approach if it gets proper buy-in.
RG
Re: JMX + MGNT
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
>> I like this idea, but I don't want to have to open a WS connection to
>> each broker, I would
>> prefer an architecture where the interface to WS-DM could be off-loaded
>> to anywhere on the network, on the
>> C++ side I would think we would create a WS-DM to AMQP-mgmt bridge. C++
>> uses the
>> following to get info in/out of the broker for mgmt
>> http://cwiki.apache.org/qpid/management-design-notes.html
>>
>
> OK this makes sense. Of course if you use a tool such as WinRM or HP
> Openview or Tivoli then it can present a consolidated view of the
> brokers.
>
>
>> I also want to make it possible to payload more than just broker mgmt
>> info on the mgnt channel.
>>
>
> Can you give some examples?
>
>
sure, as you know qpid get's included into fedora, this feature has been
picked up to also
transport OS info, CPU, interrupts, network etc.
Another project that I know that has picked it up is looking to push
data around hypervior info
And yet another is doing work laying sec alerts, and resource
utilization over the same mechanism. It turns
out it is very easy to create another mgmt object and integrate it.
So having JMX and WS-DM as standard ways to pull the mgmt off the 'bus'
would most likely increase these types
of usage of Qpid infrastructure
>> Question, go from AMQP-mgmt to WS-DM or to JMX then to WS-DM? I would
>> think straight to WS-DM but then
>> how would the Java Broker fit in? would we add the AMQP-mgnt to Java
>> broker, map JMX to WS-DM on Java side
>> etc... going to JMX is an easier community project, as many JMX
>> consoles in open source exist, don't know of any OSS
>> WS-DM ones exist
>>
>
> I'm not quite sure of the question? JMX provides an adaptor so that
> you can expose any MBean as WS-M.
>
> If I understand it, you are suggesting a separate process that speaks
> AMQP-Management to brokers but itself is exposed over WS-M. In that
> case, you'd implement the separate process in terms of JMX and it
> would then be able to support native JMX clients and WS-M clients.
>
yes, exactly.
> Is AMQP management an approved AMQP spec?
>
>
not yet ... but multiple parties in AMQP Working Group have expressed
support for it, one
of the rabbit users has been working with it also - I am sure hit will
get updated somehow before
making it's way into a release. Discussion so far is in the WG is that
it would be optional to impl as part
of the spec.
> I would obviously be interested in the thoughts of other users but in
> terms of priority, I am not convinced that implementing
> AMQP-Management is particularly pressing for the Java broker - there
> are other things our users want that offer more advantages. The reason
> is that the third party management tools do not speak AMQP-Management
> (and almost certainly never will).
>
> As it stands, by doing some testing with the Sun JMX/WS-M adapter we
> can claim out of the box HP OpenView and Microsoft WinRM (and possibly
> Tivoli) interoperability.
>
yes agree, thus I was suggesting that it is nice project for someone to
pick up, so the
bridge exists and then makes it valuable for Java broker when it gets to
it. The questions
is -- if we do a bridge as a project would that also be interesting for
the Java broker down the road?
> We should think about the things we expose over WS-M or SNMP which is
> what the users will interact with (indirectly). Ideally these should
> be consistent across the C++ and Java projects.
>
yes, there are two places we can map this, at the broker into the
AMQP-mgmt protocol or
at the impl of the bridge. I think the former is the better approach --
please comment if you
don't agree
>
>> Also, does apache WS have a WS-DM impl (Rajith..?) do you know?
>>
>
> https://wiseman.dev.java.net/ is one.
>
>
Carl.
Re: JMX + MGNT
Posted by Robert Greig <ro...@gmail.com>.
On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
> I like this idea, but I don't want to have to open a WS connection to
> each broker, I would
> prefer an architecture where the interface to WS-DM could be off-loaded
> to anywhere on the network, on the
> C++ side I would think we would create a WS-DM to AMQP-mgmt bridge. C++
> uses the
> following to get info in/out of the broker for mgmt
> http://cwiki.apache.org/qpid/management-design-notes.html
OK this makes sense. Of course if you use a tool such as WinRM or HP
Openview or Tivoli then it can present a consolidated view of the
brokers.
> I also want to make it possible to payload more than just broker mgmt
> info on the mgnt channel.
Can you give some examples?
> Question, go from AMQP-mgmt to WS-DM or to JMX then to WS-DM? I would
> think straight to WS-DM but then
> how would the Java Broker fit in? would we add the AMQP-mgnt to Java
> broker, map JMX to WS-DM on Java side
> etc... going to JMX is an easier community project, as many JMX
> consoles in open source exist, don't know of any OSS
> WS-DM ones exist
I'm not quite sure of the question? JMX provides an adaptor so that
you can expose any MBean as WS-M.
If I understand it, you are suggesting a separate process that speaks
AMQP-Management to brokers but itself is exposed over WS-M. In that
case, you'd implement the separate process in terms of JMX and it
would then be able to support native JMX clients and WS-M clients.
Is AMQP management an approved AMQP spec?
I would obviously be interested in the thoughts of other users but in
terms of priority, I am not convinced that implementing
AMQP-Management is particularly pressing for the Java broker - there
are other things our users want that offer more advantages. The reason
is that the third party management tools do not speak AMQP-Management
(and almost certainly never will).
As it stands, by doing some testing with the Sun JMX/WS-M adapter we
can claim out of the box HP OpenView and Microsoft WinRM (and possibly
Tivoli) interoperability.
We should think about the things we expose over WS-M or SNMP which is
what the users will interact with (indirectly). Ideally these should
be consistent across the C++ and Java projects.
> Also, does apache WS have a WS-DM impl (Rajith..?) do you know?
https://wiseman.dev.java.net/ is one.
RG
Re: JMX + MGNT
Posted by Carl Trieloff <cc...@redhat.com>.
Robert,
I like this idea, but I don't want to have to open a WS connection to
each broker, I would
prefer an architecture where the interface to WS-DM could be off-loaded
to anywhere on the network, on the
C++ side I would think we would create a WS-DM to AMQP-mgmt bridge. C++
uses the
following to get info in/out of the broker for mgmt
http://cwiki.apache.org/qpid/management-design-notes.html
I also want to make it possible to payload more than just broker mgmt
info on the mgnt channel.
Question, go from AMQP-mgmt to WS-DM or to JMX then to WS-DM? I would
think straight to WS-DM but then
how would the Java Broker fit in? would we add the AMQP-mgnt to Java
broker, map JMX to WS-DM on Java side
etc... going to JMX is an easier community project, as many JMX
consoles in open source exist, don't know of any OSS
WS-DM ones exist
how close do we want to get mgmt info from both brokers to be?
Also, does apache WS have a WS-DM impl (Rajith..?) do you know?
Carl.
Robert Greig wrote:
> On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> based on the mgnt thread on JMX, currently we don't us the same
>> mechanism to create mgmt info from the C++
>> broker and the Java broker. Java has JMX directly wired into, obviously
>> this can't be done in C++ so the C++ uses
>> AMQP to interact with the broker.
>>
>
> Sun has been releasing early access versions of an implementation of
> JSR 262, which is the web services connector for JMX. This means that
> you can use WS-M to manage JMX-enabled resources.
>
> WS-M in turn means that you can plug directly into a wide range of
> tools, including HP Openview and Microsoft Windows Remote Management
> (WinRM). The main players all support WS-M (MS, IBM, HP).
>
> This was always my vision for the management work. I think we need to
> be able to support third party tools, and WS-M or SNMP are the obvious
> ways of doing this.
>
> To bring these together, could the C++ broker be made to support WS-M?
>
>
>> Is this a direction we want to take, and if so this is also a very nice
>> area for someone to work on the project. I have had someone
>> approach me from community to work on the project and this seems like a
>> good place to start if this is a direction we want to go in.
>>
>
> It would be an interesting project for someone to get the WS-M early
> access implementation and make it work with Qpid:
> http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/
>
> RG
>
Re: JMX + MGNT
Posted by Robert Greig <ro...@gmail.com>.
On 14/03/2008, Carl Trieloff <cc...@redhat.com> wrote:
> based on the mgnt thread on JMX, currently we don't us the same
> mechanism to create mgmt info from the C++
> broker and the Java broker. Java has JMX directly wired into, obviously
> this can't be done in C++ so the C++ uses
> AMQP to interact with the broker.
Sun has been releasing early access versions of an implementation of
JSR 262, which is the web services connector for JMX. This means that
you can use WS-M to manage JMX-enabled resources.
WS-M in turn means that you can plug directly into a wide range of
tools, including HP Openview and Microsoft Windows Remote Management
(WinRM). The main players all support WS-M (MS, IBM, HP).
This was always my vision for the management work. I think we need to
be able to support third party tools, and WS-M or SNMP are the obvious
ways of doing this.
To bring these together, could the C++ broker be made to support WS-M?
> Is this a direction we want to take, and if so this is also a very nice
> area for someone to work on the project. I have had someone
> approach me from community to work on the project and this seems like a
> good place to start if this is a direction we want to go in.
It would be an interesting project for someone to get the WS-M early
access implementation and make it work with Qpid:
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/
RG
JMX + MGNT
Posted by Carl Trieloff <cc...@redhat.com>.
Marnie, all,
based on the mgnt thread on JMX, currently we don't us the same
mechanism to create mgmt info from the C++
broker and the Java broker. Java has JMX directly wired into, obviously
this can't be done in C++ so the C++ uses
AMQP to interact with the broker.
As project do we want to at some point bring the way we do this on both
brokers together? I would expect so, but there are
a few pieces that need to be done in increments. For example we would
need to create a JMX bridge before we integrate
into the Java broker.
Is this a direction we want to take, and if so this is also a very nice
area for someone to work on the project. I have had someone
approach me from community to work on the project and this seems like a
good place to start if this is a direction we want to go in.
thoughts?
Carl.
Re: GSoC 2008-Qpid projects
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ru...@wso2.com> 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
>