avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Huw Roberts <...@apache.org>
Subject Re: MBean suffixed classes
Date Tue, 13 Aug 2002 08:01:23 GMT
My long day, late night, two cents on this.

Hi Alexis, you wrote on 8/12/02 10:48:20 PM:

>Paul Hammant wrote:
>> Huw, Peter, Folks,
>> I have to say I dislike the MBean suffix for JMX enabled beans.  In fact 
>> it is my principle objection to JMX (yes I know it is anal).
>I agree
me too :)

there is no requirement for the MBean interfaces, you can mark up the components directly,
and they will get managed.  we discussed taking them out, but felt it wasn't wise with the
beta being imminent (sp?). also, Peter D mentioned a usage where the user would be able to
cast the managed object back to its interface, and taking them breaks that until the grand
plan is realized. 

>> Would it be possible to generate them?
>> Consider that a simple Service could be :
>>  interface MyThing {
>>      /** @phoenix:manage-me */
>>      void hello();
>>  }
>> And its class could be :
>>  class MyThingImpl implements MyImpl, Startable {
>>      public MyThingImpl() {
>>      }
>>      public void start() {}
>>      public void stop() {}
>>     // etc.
>>  }
>> Perhaps, we could use xdoclet to make :
>>  interface MyThingMBean {
>>      void hello();
>>  }
>> And :
>>  class MyThingImplMBean extends MyThingImpl implements MyThingMBean {
>>  }
>> Thus we could hide the MBean stuff.  This could either be done as part 
>> of the regular Ant compile target, or be done at runtime by Phoenix 
>> using BCEL.
yes, i think we can do this straight from the mxinfo file, using BCEL or some other craftiness.
 the interface would have the methods and operations as described in the mxinfo file, with
additional info drawn from the class at runtime.  

i'm volunteering to do this :), but i'm in crunch mode at work this (and last) week.  

>> It would also be possible to model some nice things like a state machine 
>> for blocks.  For example start() and stop() hint at a state change. BCEL 
>> could generate
>>  class GeneratedBlockNNNN extends MyThingImpl {
>>      boolean blockStarted;
>>      public void start() {
>>        super.start();
>>        blockStarted = true;
>>      }
>>      public void stop() {
>>        super.stop();
>>        blockStarted = false;
>>      }
>>      public isStarted() {
>>        return blockStarted;
>>      }
>>  }
>> It would be useful for the BeanShell enabled kernel which can traverse 
>> objects without constraint.
>BCEL or ant are good.
>Just to suggest another way, I would propose that a componant 
>could implement an interface, let say "Managable" that require a 
>method such as getManagedMethod() returning all managed method.
>class MyThingImpl implements MyImpl, Managable {
>	void Hello(){
>	}
>	... getManagedMethod(){
>		something.add( ... "Hello"... )
>		return something;
>	}
>so this could maybe validated at compile time.

This sounds a little like what you can already do with the in-memory model of the mxinfo files,
which right now is an implementation of RequiredModelMBean and related classes.  We went to
a fair bit of trouble to reuse those classes to keep the code base small - but we're free
to swap it out for some other object model/implementation since its all hidden within the
management component.  (That's why a like this scheme - component authors only need to know
the xdoclet markups and/or the mxinfo format - the rest is determined by the container)

>Also some componant implementing some interface such as Startable 
>or Configurable (or whatever) could be managed "defacto".

Can do this now, but not as part of the mxinfo markup.  Basically 'management' code (like
that which registers blocks), needs to do an instanceof on the component and if it implements
a certain interface, also export a topic for that interface.  i'd like to do it for logging
as a POC, but haven't had time to find a friendly way to work that in.

>As you suggested, Startable could have start/stop managed.
>Configurable componant could have its configuration writable thru 
>JMX (ok this is not obvious considering the configuration hierarchy).
>And so

Taken to the extreme, we could do all configuration via the exposed management methods.  Configuration
would become a script that drives startup through the various stages.  I like the idea in
the abstract - but don't know how practical or useful that would be.  Might lead to some interesting
exchanges though...

It sounds like we have broad agreement on the direction we want to go.  First things first,
I'd like to document the whole xdocs --> mxinfo --> targets --> topics --> mbeans
scheme.  That's my goal for this week.  

Whoever thought management could be so much fun?
- Huw

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>

View raw message