Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 21 Jul 2005 18:52:05 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org
Subject: Re: Management API
In-Reply-To: <7b3355cb050718204042bfcb18@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0507211845370.10010@saturn.opentools.org>
References: <Pine.LNX.4.58.0507162027190.20976@saturn.opentools.org>
 <7b3355cb050718204042bfcb18@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	Dain, David J, and I talked about management options on IRC.  I 
put a writeup on the Wiki (top of the page, with the original proposal 
below):

http://wiki.apache.org/geronimo/Geronimo_Management_API

	I also have an IRC log if anyone cares, but I think the writeup is
more coherent.  :)

	Also, to address the JSR-77 point in the message below, this in no
way reduces our JSR-77 compliance.  It's just adding a "friendlier" option
in addition to JSR-77.  You can always use pure JSR-77 if you're a 
masochist (or just really really need portable code).

Thanks,
	Aaron

On Mon, 18 Jul 2005, Bruce Snyder wrote:
> On 7/16/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> >         So after looking at the web console code and the JSR-77 spec, I
> > got the idea in my head that we could use a management API made up of
> > actual classes and interfaces, instead of object names and attribute
> > names.  This is not meant to replace JSR-77 as a portable interface across
> > servers and protocols, and not meant to replace GBeans and the Kernel as a
> > method to inspect and tweak every last property of any object available in
> > any Geronimo configuration.
> > 
> >         It is meant to make it easier to develop management tools (such as
> > the web console) against the common case of the Geronimo J2EE server.
> > 
> >         Anyway, since I've gotten trouble over long e-mails before, I
> > wrote up what I have in mind and why I think it's a good idea (compared
> > to the management options we have now) on the Wiki:
> > 
> > http://wiki.apache.org/geronimo/Geronimo_Management_API
> 
> Geez, that's just as bad as a long email ;-). 
> 
> Taken from the URL above: 
> 
> [And if we're going to be reusing code across tools, I would much
> rather it be an API layer like this, not copying and pasting kernel
> invocations with string arguments and so on.]
> 
> I agree completely and have always thought this when looking at that
> code. It just seems very brittle. But I share the same concerns as
> David and so I pose these questions: Aren't we just prolonging the
> period of instability by continuing to change APIs as it suits us?
> What if this work is undertaken and then someone else pops up with a
> valid reason to provide strict JSR-77 compliance?
> 
> Also taken from the URL above: 
> 
> [Suggestion... create this layer in a reusable(extensible?) manner, to
> enable the creation of other G-management APIs applicable when
> Geronimo assumes other "personalities" (J2EE subset, J2EE superset, no
> J2EE - purely embedded, etc)]
> 
> Couldn't this be accomplished in some way by using the dependency
> system provided by the kernel? E.g., upon startup of management
> console, check to see if web container X is running; if yes then
> deploy the web container X management portlet, else don't deploy it,
> etc. Just a thought.
> 
> Bruce 
> -- 
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
> 
> The Castor Project
> http://www.castor.org/
> 
> Apache Geronimo
> http://geronimo.apache.org/
>