geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Management API
Date Tue, 19 Jul 2005 03:40:36 GMT
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/

Mime
View raw message