Quoting Trustin Lee <[EMAIL PROTECTED]>:
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
With DynamicMBean, you must provide your a MBean class for each
managed resource with its own MBeanInfo/AttributeList. This could be a
tedious task.
ModelMBean seems more appropriate in this case, but it requires to set
up a lot of metadata. Fortunately, Jakarta Commons Modeler can be used
to reduce the amount of code to write.
The best would probably be OpenMBean (easy integration with SNMP), but
IO don't know any utilities such as Commons Modeler for OpenMBean.
BTW, Spring has great JMX integration features.
Cheers,
J-F
