Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Matt Kurjanowicz" <mkurjano@cc.gatech.edu>
To: <geronimo-dev@incubator.apache.org>
Subject: RE: [newbie] JMX Console - where to start?
Date: Mon, 1 Sep 2003 22:38:17 -0400
Message-ID: <001501c370fb$442a9750$75493d80@mkurjano>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.44.0309011953130.1974-100000@www.princetongames.org>
Importance: Normal

The Wiki looks good.
I added a few sections, one about a Swing/SWT client, and another about
abstracting the client layer out of JMX.  This would be kind of like
creating a management middleware.  That way, the client would only
become a front-end to this middleware, and it would be relatively easy
to build a client for this middleware (be it Command Line, Web,
Swing/SWT, Applet, whatever).  The command structure would actually be
client independent.  This would facilitate a few things:
* Any client could be built that would use this middleware to perform
the commands of the server
* A deployer of the Geronimo Server could write their own custom
Management console (if they don't like what's been developed) without
having to know the intricacies of the JMX and the Geronimo backend.
* New clients, as needed, could focus on the presentation of the JMX
data rather than the collection of it. * The abstraction of the
management out of the direct hands of a developer.  This could allow
Geronimo to employ stricter security.
OR
* The Client can still talk JMX to anything if it wants

A little more clarification:

                                      <-JMX-> OTHER ITEMS
CLIENT <-CUSTOM CODE-> MANAGEMENT_API <-JMX-> COMPONENTS
                                      <-JMX-> SERVICES

This looks an awful lot like rewriting JMX, but the way that this is
different is by making it easy for the CLIENT to talk to the services
and Geronimo components, without having to know exactly how they are all
managed.  (something like
(not exactly)
ManagementCommunicator.startService("SERVICE_NAME");
ManagementCommunicator.startServer();
ManagementCommunicator.getServerStatus();
ManagementCommunicator.getComponentStatus("COMPONENT_NAME"); )

What do y'all think about this?

I know some parts of this are redundant...sorry.
-Matt
mkurjano at cc.gatech.edu

-----Original Message-----
From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
Sent: Monday, September 01, 2003 8:00 PM
To: 'geronimo-dev@incubator.apache.org'
Subject: RE: [newbie] JMX Console - where to start?

	There's now a Wiki page at:

http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/ManagementClient

	It's also available from the main Geronimo page if you follow
the 
link to /Architecture and then /ManagementClient

	I put the contents of this thread so far on there, but I'd 
encourage others to add more.

	I also added a /ServerManagement page at the same location, but 
I'm too rusty on JSR-77 to say much useful there.  Perhaps someone who's

working in that area could describe the JSR-77 object model, and how a 
client could access it?

Aaron

On Tue, 2 Sep 2003, Nick Faiz wrote:
> Putting it on a wiki page would be very useful. 
> 
> Also, how are server instances represented in Geronimo? 
> 
> Just to throw some obvious needs at the screen for the JMX console. We
could
> also consider sections for
> 
> - datasources, jdbc connection pools and the usual list of things
you'll see
> in a J2EE console.
> - users / groups. Are we using the typical ACL model?
> - the adjustment of logging levels (it would be terrific if we could
view a
> stat.s graph of server usage).
> - possibly, a list of active sessions.
> 
> Let me know if I can help out in this area. It's hard to know where to
jump
> in.
> 
> Nick
> 
> -----Original Message-----
> From: Matt Kurjanowicz [mailto:mkurjano@cc.gatech.edu] 
> Sent: Tuesday, 2 September 2003 7:55 AM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: [newbie] JMX Console - where to start?
> 
> Stepping back makes sense...
> At the most basic level, I think we would need:
> * start/stop/restart/kill server
> * start/stop individual components (?)
> * add/remove components (?)
> * check status of server/individual components
> * list/start/stop services
> 
> >From there, I think we would need to build some more advanced
> functionality:
> * Change configuration of server on the fly
> * List configuration (? - basic?)
> * Manage (in more depth than start/stop/list)/Configure Services
> (necessary?)
> 
> I think this is a really restricted list, and just takes into account
> the most basic items.  As far as how to implement this functionality,
a
> command line interface would be nice and simple for the simpler tasks,
> but it would be a little more difficult to say, configure the server
> using a command line versus using a web/swing type framework.
> 
> -Matt
> mkurjano at cc.gatech.edu
> 
> P.S> Where in the Wiki would a page about this go?
> 
> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> Sent: Monday, September 01, 2003 4:54 PM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: [newbie] JMX Console - where to start?
> 
> 	Twiddle is the command line framework I'm referring to.  If you
> look at o.a.g.command.StartCommand (in the core module), you'll see
how
> to
> construct a command to tke advantage of it.
> 
> 	But perhaps it would be best to step back a sec and start at the
> 
> top.  Shall we start a Wiki page on the topic, and assemble a list of
> what 
> functions we think the JMX console should have?  It might help to talk

> through the functionality we're going for, and then see what that
> suggests 
> when it comes to the implementation.
> 
> Aaron
> 
> On Mon, 1 Sep 2003, Matt Kurjanowicz wrote:
> > As far as which angle (command line, web, etc.), I'm interested in
any
> > of those.  Is Twiddle what you are talking about on the command
line?
> > 
> > Expanding the Tomcat code sounds like a really interesting idea, but
> I'm
> > not familiar with the code behind it.
> > 
> > I am not completely familiar with JMX and JSR -77 and -88, but I am
> > definitely willing to learn.  To be completely honest, I'm really
new
> at
> > J2EE stuff, but have lots of time and willingness to learn, so I've
> been
> > playing around with different J2EE components, but nothing
spectacular
> > so far.
>