I somehow missed the initial post...looks good. I'd say (only thinking
about that now) it is indeed a little better to keep javadoc for docs.
You may know I've been looking at netbeans ;), and they use either the
manifest file format, or xml when that is too limiting. Which sounds
sensible enough.
cheers,
- Leo
On Mon, 2002-06-17 at 00:49, Peter Donald wrote:
> 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:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
