geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "n. alex rupp" <rupp0...@umn.edu>
Subject Re: JMX Management Console
Date Wed, 03 Sep 2003 06:36:41 GMT
I've figured out a pretty simply way to format the JSR 77 components in a
tree view in the web console.  Shouldn't take much effort to pull it off, I
don't think.  I'll be including it in the next release of the console,
hopefully rolling out by the end of the week.

> I guess either reflection or a previously configured list could
> identify the type of resource - see page 20 of JSR 77 v 1.0.

Best,
--
N. Alex Rupp (n_alex_rupp@users.sf.net)




----- Original Message -----
From: "Nick Faiz" <nick.faiz@ce.com.au>
To: <geronimo-dev@incubator.apache.org>
Sent: Tuesday, September 02, 2003 8:24 PM
Subject: RE: JMX Management Console


> Aaron,
> Nice work at the wiki!
> I guess either reflection or a previously configured list could
> identify the type of resource - see page 20 of JSR 77 v 1.0.
> I'm going to read JSR 77 through tonight and participate on this
> side of things a little more.
>
>
> Nick Faiz
>
>
> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Sent: Wednesday, 3 September 2003 10:14 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: JMX Management Console
>
> Gianny,
>
> Thanks -- this was extremely helpful.  Now that you mention the
> MEJB, some of this is starting to click.  Of course, we have to get beans
> running in the server before we can interact with the MEJB, but at least I
> know where we're going.
>
> Let me ask this -- the J2EEServer interface provides a method
> (getResources) to get all the resources available in the server.  Is it
> them up to the management console to look through all those resources
> individually and establish their resource type?  It doesn't seem like
> there's a "Resource" interfaces with a "getType" method or a
> "getResourcesByType" method on server, so it seems like in order to
> populate a nice BEA-like tree, you'd have to look up all these objects
> and check the methods provided by each one to figure out which is which.
> Is that right?  Is this an area that could be better-developed in the
> managed object tree, or are we kind of stuck with what's there on account
> of the JSR-77 spec?
>
> Thanks,
> Aaron
>
> P.S. I added a lot of your message to the Wiki, I hope that's OK:
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/ServerManagement
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/ManagementClient
>
>
> On Wed, 3 Sep 2003, gianny DAMOUR wrote:
> > Hello,
> >
> >
> > Aaron Mulder wrote:
> > [...]
> > >restart JNDI (or whatever) also talks about the consequences?  And how
> > >would you present server components vs. applications and application
> > >components (hopefully not in one big alphabetical list!)?
> >
> > Personally, the management console of BEA is outstanding. Basically,
they
> > have broken down the components into areas (JNDI, Datasources, Web
> > applications et cetera) and the result is that it is quite intuitive to
> > understand/find how to use the management console.
> >
> > Just right now, Geronimo provides distinct management domains
> > "geronimo.boot", "geronimo.deployment" et cetera which breaks down the
> > server components into distinct area and I assume that it will be the
> > mechanism to aggregate the components.
> >
> > Regarding the presentation of the JSR-77 manageable objects, perhaps
that
> > this kind of layout could be applied (excerpt):
> >
> > + J2EEDomain (name=<name>)
> >    |----------J2EEServer (name=<name>)
> >                       |----------J2EEApplication (name=<name>)
> >                                          |----------AppClientModule
> > (name=<name>)
> >
> > This hierarchy mirrors the parent j2ee type hierarchy defined by
> > JSR77.3.1.1.1.3. It could be nice to be able to click on a specific
> > manageable object, which then opens and displays its childs or related
> > manageable objects.
> >
> > Moreover, as the objects provide a status (stopped, running, failed et
> > cetera), one could also add a small icon (red=stopped; green=running)
> beside
> > each folder in order to display its status.
> >
> > > As far as coding goes, the first thing to do is figure out how to
> > >access all the goodies in o.a.g.management from a remote client.  It
> looks
> > >like most everything is an interface at the moment -- my guess would be
> > >that it's not implemented yet on the server side -- anyone know more
> about
> > >the progress there?  Is there something we can poke just to make sure
the
> > >communication works?
> >
> > All the "goodies" in o.a.g.management should be accessed via at least a
> > session bean, named a MEJB, which MUST be deployed in order to be
> compliant
> > with JSR77. This EJB exposes the management model as (Dynamic) MBeans.
> More
> > accurately, the manageable objects may or may not be MBeans, in our case
> > they will be (Dynamic) MBeans, and should not be accessed directly. One
> > should use the MEJB home anrd remote interfaces to interact with them as
> > MBeans.
> >
> > > Finally, I would also like to hear more about the web-based
> > >console.  I'm not sure what state it's in and whether help is wanted.
We
> > >can plan to work on the command-line version for now, though it sounds
> > >like perhaps we have people interested in both.
> >
> > Regarding the web-based console and the command-line version, I only
> wanted
> > to underline that it should be able to alert the end-user of
> notifications.
> > Indeed, manageable objects may emit notifications (e.g. when its status
> > changes) and a management application may listen to them.
>



Mime
View raw message