avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject RE: management GUI
Date Sun, 16 Jun 2002 22:49:32 GMT
At 03:28 PM 6/15/2002 -0700, you wrote:
>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,

wooohoo!

>  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 -->
>   <services>
>     <service name="org.apache.avalon.ftpserver...."/>
>   </services>
>
>   <!-- management methods exposed by block -->
>   <management>
>     <!-- proxy class if there is one -->
>     <proxy name="org.apache.avalon.ftpserver.FtpServerMBean" />
>
>     <!-- operations -->
>     <operation
>       name="getServerPort"
>       description="Returns port that the server listens on"
>     >
>       <param
>         name="instance"
>         description="no description"
>         type="java.lang.Integer"
>       />
>     </operation>
>     <!-- attributes -->
>     <attribute
>       name="defaultRoot"
>       description="Returns the top level directory that is published"
>       isWriteable="false"
>     />
>   </management>
>
>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.

Sounds fantastic. The one thing that imedaitely struck me was that the 
utility code may be useful outside the context of phoenix. ie It would be 
great to be able to use the same descriptor format in another program.

The best way to resolve this would be to create another descriptor named 
<classname>.xmbean - so you would end up with

<classname>.xmbean
<classname>.xinfo
<classname>.class

Then the management system could do something like

class MBeanUtil
{
   static Object createMBean( final Object object )
   {
     final InputStream in =
         object.getClass().loadResourceAsStream( 
object.getClass().getName() + ".xmbean" );
      if( null == in ) return null;
     Configuration c = buildFrom( in );
     return new ConfigurationMBean( object, c );
   }
}

This would allow the same descriptor to be used in more locations.

>The biggest change to Phoenix to get this working is around the
>SystemManager interface, since it currently expects an array of interfaces.

Thats fine.

>Funtionality of existing blocks would not be affected, although they lose
>there manageability until they are modified.

Unfortunately we need to maintain backward compatability IMO. We could 
implement the above system and still maintain backward compatability. That 
way people could still export blocks via an interface or via the new mbean 
descriptor depending on their whims. Thoughts?

>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.

Please!

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


Good reaction so far. The only thing that may be an issue is that some 
people have preferred to expose management info via an interface rather 
than directly. The main reason for that is that you could then auto create 
a JDK1.3 proxy on clientside of JMX thus allowing you to work with normal 
java objects rather than via the MBeanServer (which is a lil painful).

Not saying you shoudl adopt this but something to think about ;)


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message