Management Metainfo

[Huw Roberts <Hu...@mmlive.com>]

As part of the management work, there is a process where various classes are
instrumented and then exported into a structured (hierarchal) repository.
There are various sources for the metainfo about how an object should be
presented in the management system.  The first two sources of metainfo are
(1) the introspection of the mgmt interfaces defined when the object is
exported, and (2) xml files that are directly parsed for the metainfo.

We need to select the format for how the metainfo will be stored internally.
I can think of three options
1) new classes written for this purpose
2) the java.beans classes plus a limited number of new classes
3) the model mbean classes plus a limited number of new classes

i thought about it a lot, and believe that using the model mbean classes
makes the most sense.  there would also be a limited number of custom
classes to represent the additional structure that managed classes inherit
from being written for/deployed to phoenix.  the only draw back i can see is
that as the jmx spec evolves phoenix management would need to stay more or
less in step.  i think its worth the tradeoff.  does anyone have any
thoughts/preferences?

assuming that's good, i did a search on google for jmx and xml and one of
the first things i came across was the common's own modeler package.  it
includes utility classes for contructing model mbeans, and includes the code
to generate them from xml.  would it be expedient to adapt that to our
purposes?  if so, would it get copied to excalibur?  i don't know phoenix
stands wrt to the commons as they seem to overlap in some areas.

i'll take what advice i'm given and run with it.

- huw

Re: Management Metainfo

[Peter Donald <pe...@apache.org>]

On Wed, 17 Jul 2002 14:06, Huw Roberts wrote:
> We need to select the format for how the metainfo will be stored
> internally. I can think of three options
> 1) new classes written for this purpose
> 2) the java.beans classes plus a limited number of new classes
> 3) the model mbean classes plus a limited number of new classes
>
> i thought about it a lot, and believe that using the model mbean classes
> makes the most sense. 

sounds good to me.

 there would also be a limited number of custom
> classes to represent the additional structure that managed classes inherit
> from being written for/deployed to phoenix.  the only draw back i can see
> is that as the jmx spec evolves phoenix management would need to stay more
> or less in step.  i think its worth the tradeoff.  does anyone have any
> thoughts/preferences?

I like JMX and think thats probably the best way to move. I would prefer it if 
no actual JMX code needed to be in the .sar file (I don't believe it does?) 
and it was all done in the manager. (The manager can load xml descriptors via 
classes like object.getClass().getResourceAsStream("blah.xmbean");

> assuming that's good, i did a search on google for jmx and xml and one of
> the first things i came across was the common's own modeler package.  it
> includes utility classes for contructing model mbeans, and includes the
> code to generate them from xml.  would it be expedient to adapt that to our
> purposes?  if so, would it get copied to excalibur?  i don't know phoenix
> stands wrt to the commons as they seem to overlap in some areas.

I haven't actually looked at the commons one. I vaguely recall that it 
registered a bunch of different mbeans per descriptor rather than just one. 
Thus it is probably not suitable for us as such. Though it would be useful to 
use the same or similar format to describe the mbeans.

-- 
Cheers,

Peter Donald
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten.                --Jules Feiffer (cartoonist) 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>