In our application we use StandardMBeans and we limit the interface to open mbean types (this will be much easier in JDK 1.6 where MXBeans are more complete) to make sure that clients don't need any jar files.
In order to make it very easy to implement (from the programmer's perspective) we do the following:
All mbeans implement (generally indirectly) the following interface:
public interface ManagedObject
{
static final String DOMAIN = "ourjmxdomain";
/**
* @return the name that uniquely identifies this object instance. It must be unique only among objects
* of this type at this level in the hierarchy so the uniqueness should not be too difficult to ensure.
*/
String getObjectInstanceName();
/**
* @return the type that confirms to mbean naming conventions for exposing a hierarchy
String getType();
Class<?> getManagementInterface();
void register() throws AMQException;
void unregister() throws AMQException;
}
The return value from getManagementInterface() is generally passed into the constructor of StandardMBean. This allows us to control exactly which methods are exposed.
There is a default implementation of the the interface which most of the MBeans extend, so that the details of registration and so on don't need to be considered.
Generally we make the MBeans inner classes, and this makes it easy for them to expose existing functionality without having to change existing classes. In many cases our mbeans are just subsets of existing classes with some transformations made to return open mbean-compatible types.
RG
| "Trustin Lee" <[EMAIL PROTECTED]>
15/05/2006 06:29
|
To: [email protected] cc: Subject: Package for JMX integration |
Hi,
I saw Peter checked in ThreadPoolFilterMBean today. Actually I was thinking
about adding JMX integration classes to
org.apache.mina.integration.jmxpackage. Would this be a bad idea?
For example,
ThreadPoolFilter f = ...;
// ThreadPoolFilterMBean is not an interface but an implementation of
DynamicMBean (perhaps by extending StandardMBean).
server.registerMBean(new ThreadPoolFilterMBean(f), new ObjectName(...));
My idea behind this is to isolate JMX from the implementation because JMX is
not the only integration we will provide. It is somewhat cumbersome to
implement DynamicMBean, but it will give us much more control and users more
description from JMX console. WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
