Hi J-F, Long time no see first of all! :)
On 5/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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.
Thank you for the great information. We'll definitely consider all possible solutions. Cheers, 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
