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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
