qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lahiru gunathilake" <glah...@gmail.com>
Subject Re: GSoC - Lahiru's CLI for JMX
Date Fri, 16 May 2008 11:27:52 GMT
HI Aiden,

Thanks a lot for the reply and as you said I have to think about a structure
of the project and think from the users side and honestly that's what I was
doing today morning and I have certain questions on and certain suggestions
as well and need a feed from you and Marnie.

On Fri, May 16, 2008 at 3:13 PM, Aidan Skinner <aidan@apache.org> wrote:

> On Fri, May 16, 2008 at 6:54 AM, lahiru gunathilake <glahiru@gmail.com>
> wrote:
> > On Thu, May 15, 2008 at 9:59 PM, Marnie McCormack <
> > marnie.mccormack@googlemail.com> wrote:
> >> sure this is possible.I have already develop a util  package which is
> >> capable of handling any option and I just have to add some code when I
> want
> >> to add new option and I can use that to make the required task to happen
> >> with the new option.
> What package are you using for this? What does it provide over, say,
> commons-cli?

I wrote a package called util which handle options. As an example for now
options are like this(this is the command I used to run it with options)
javac -h localhost -p 8999 -i 4000 -o /home/lahiru/

I put all the default values for the options.
-h - hostname of the broker you are going to monitor
-p - port number
-i - time interval user wants to get informations to extract
-o - output location of the file which writes the output

This is what I wrote in my package I wrote which is handling different

> > Yes that's true I just got all the attributes to check what's going on
> > inside JMX instrumentation in Qpid. I think we have to take all the
> mbeans
> > and all the attributes in to a single object and give the whatever
> > information user ask time to time.
> It depends on how you implement it, for a simple one shot command it
> probably makes sense to only query the objects that you need to
> provide the data. For a more complicated report you may need to query
> several objects, I don't see why you would munge them all together
> though.

Sorry here, me too think no need to do that since we are having the
MBeanServerConnection object with us so any time we can query for fresh

> > I will send you a list of things I'm going to do in next two week
> today..!
> > Please tell me any thing wrong with my idea or am I going in a wrong
> > direction...
> I think you probably want to step back a little and think about what
> you're going to do, and how, rather than leaping into the doing part
> feet first. Coding isn't due to start in earnest until the 26th, so
> you have some time to consider what you're doing. Planning is
> important, particularly when you're talking about a relatively large
> chunk of work like this. Having a prototype is good, but it's no
> substitute for really taking the time to learn about problem domain. I
> think it would be worthwhile to have a think about this from the users
> perspective and ask yourself questions from the point of view of a
> system admin, things like "what information would I want to get out of
> the broker?""What would I want to feed this data too? Is it easily
> awk'able?" "How can I get this written to a logfile that I can use to
> monitor the state of the broker?"

Thanks aiden, I will write about the structure I created with my project and
honestly I started on developing it from the day I had a chat with you and I
changed it time to time with the feed I got from you and marnie.
hope to send it tomorrow.

Thanks in advance


> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com <g%3Aaidan.skinner@gmail.com>
> http://aidan.skinner.me.uk/
> "We belong to nobody and nobody belongs to us. We don't even belong to
> each other."


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message