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