Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Tue, 2 Sep 2003 20:13:46 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: geronimo-dev@incubator.apache.org
Subject: Re: JMX Management Console
In-Reply-To: <Sea1-F80fRS8LbyiDFk00002353@hotmail.com>
Message-ID: <Pine.LNX.4.44.0309022004450.7735-100000@www.princetongames.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.