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 <[EMAIL PROTECTED]> 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)[EMAIL > PROTECTED]&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/ >
