avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Huw Roberts <...@mmlive.com>
Subject RE: management GUI
Date Sat, 15 Jun 2002 22:28:23 GMT

I've been looking at an alternative 'pluggable management protocol' that i
think will work across the spectrum of requirements and preferences.  I've
got it more or less working, and now I'm looking for your
reactions/comments. So here's the pitch.

>From the Block developers POV:

For a block to be manageable, the developer inserts a series of XDoclet tags
in the class file.  Right now these are:

At the class level:

   * Ftp server starting point. Avalon framework will load this
   * from the jar file. This is also the starting point of remote
   * admin.
   * @phoenix:block
   * @phoenix:mx  
   * @phoenix:service name="org.apache.avalon.ftpserver...
  public class FtpServerImpl extends AbstractLogEnabled

where @phoenix:mx marks the block as eligible for management.

For each attribute:

     * @phoenix:mx-attribute
     * @phoenix:mx-description Returns the top published directory
     * @phoenix:mx-isWriteable false
    public String getDefaultRoot() {

and finally for each operation:

     * @phoenix:mx-operation
     * @phoenix:mx-description Returns port that the server listens on
    public String getServerPort(Integer instance) {

When this is compiled the PhoenixDoclet task extracts this and inserts it
into the xinfo file.  Here's what the entry gerated from the tags above:

  <!-- services that are offered by this block -->
    <service name="org.apache.avalon.ftpserver...."/>

  <!-- management methods exposed by block -->
    <!-- proxy class if there is one -->
    <proxy name="org.apache.avalon.ftpserver.FtpServerMBean" />

    <!-- operations -->
      description="Returns port that the server listens on"
        description="no description"
    <!-- attributes -->
      description="Returns the top level directory that is published"

This data is loaded into a ManagementDescriptor object, and this object,
along with the block is what is 'export'ed to the SystemManager.  I've
written a 'ConfigurationMBean' class (based on excalibur-baxter classes)
that creates the appropriate MBean, so that angle is taken care of.
Assuming it gets of the ground, it should be straightforward to write
additional adapters for a scripting (beanshell, ant?), soap, gui, etc.

The biggest change to Phoenix to get this working is around the
SystemManager interface, since it currently expects an array of interfaces.
Funtionality of existing blocks would not be affected, although they lose
there manageability until they are modified.

So that's that.  I'd love to finish this up and submit it for inclusion in
Phoenix, and then do at least some of the above management adapters.  If
you'd like to see the source let me know and i'll send them in.  

I'm happy to work details later, but for right now would really like to know
your general reaction.

-----Original Message-----
From: Paul Hammant
To: Avalon-Phoenix Developers List
Sent: 6/15/2002 1:23 PM
Subject: Re: management GUI

Leo, Folks.

>hmm. Phoenix already has pluggable management protocol (the only one
>is JMX though). I'm thinking either a client that talks to the
>MBeanServer in phoenix, or one that talks to a different kind of server
>(maybe SOAP or something BSH-like).


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message