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 <[EMAIL PROTECTED]> wrote: > On Fri, May 16, 2008 at 6:54 AM, lahiru gunathilake <[EMAIL PROTECTED]> > wrote: > > > On Thu, May 15, 2008 at 9:59 PM, Marnie McCormack < > > [EMAIL PROTECTED]> 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 options. > > > > 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 information. > > > > 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 Regards lahiru > > > - Aidan > -- > aim/y!:aidans42 g:[EMAIL PROTECTED] <[EMAIL PROTECTED]> > http://aidan.skinner.me.uk/ > "We belong to nobody and nobody belongs to us. We don't even belong to > each other." > --
