Re: Proposal draft for Tomcat 5.0 : JMX utils

["Christopher K. St. John" <ck...@distributopia.com>]

costinm@covalent.net wrote:
> 
> I don't think model mbeans can be used for some of the
> stuff that I want ( in jk ), and I think it is much easier to
> use the automatic introspection based dynamic mbeans.
>

 Hmm, I don't get it. Might be me not understanding JMX
well enough (need to buy that darned book), but:

 Model MBeans are Dynamic MBeans. The can set themselves
up automatically using introspection, but you end
up not having all the meta data. So people tend to write
utilities (like commons-modeller or JBoss's XMBeans) to
help manage the meta-data. 

 The MBeans in o.a.c.mbeans actually implement concrete
wrapper classes around the managed resource, but that's
a bit unusual, and most of them could just use
introspection.

 Since ModelMBeans are Dynamic MBeans, what sorts of 
problems were you running into? There was some mention
of yet-another format for XML MBean meta-data files, is
that really the plan?
 

-- 
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com

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

Re: Proposal draft for Tomcat 5.0 : JMX utils

[co...@covalent.net]

On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:

>  Hmm, I don't get it. Might be me not understanding JMX
> well enough (need to buy that darned book), but:

:-)

>  Model MBeans are Dynamic MBeans. The can set themselves
> up automatically using introspection, but you end
> up not having all the meta data. So people tend to write

As IsA, you're right, Model extends Dynamic. 

The use is very different - with model you create a 
MBean and (based on a config file) specify the fields
and methods. 

With Dynamic - you have to create a class extending the base
class and implement the methods. That can be done using 
introspection ( instead of the config file ) or you can 
use whatever other mechanism - like sending requests over
the wire and act as a proxy for some non-java code. 

The implementation details are not that important - both
are reasonably simple and clean, I don't see a problem
with using multiple methods to get the MBean registered.

After all, that's what matters - to have all aspects managed
by mbeans.

Costin



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