Hi, > Using model mbeans instead of standard mbeans has many > advantages.
Uhm, I admit to have little knowledge of JBoss' XMBean, but what are the real advantages of using ModelMBeans (and all the stuff they carry) ? I think it can be useful to have DescriptorAccessible MBean*Info, but once again, how do you configure it ? > As I recall someone (Simone?) offered to write an xmbean model mbean for > mx4j. Yes, it was me :) I even started, but stopped after a while failing to see a definite use case for them. I don't say they don't have a useful use case, but that I fail to see it. Lack of experience on my part, I imagine. ModelMBeans are a pain to configure (very verbose xml files) while most of the times the metadata can be obtained from the resource (at the end, you want to call its methods: why not generating the metadata automatically - a la std mbeans - and add only useful stuff ?). I need a clear use case for XMBeans. > We can use the xdoclet JBoss xmbean template as a > starting point > and generate the xml descriptor from the source. Wouldn't that look too similar to JBoss ? > For now we can generate standard mbean interfaces and, when we get an > xmbean impl. switch over with minimal effort. Including > appropriate documentation now will make the switch easier. This brings me to another question: how difficult is to move to a plain java object (a la Avalon) and have an XMBean that can wrap java objects automagically ? If the microkernel is responsible to create the various components, then it can also XMBean-wrap them (or not). Another point worth to discuss is invocation performance: remember that calling via JMX is waaaaaay slower than with reflection: the MBeanServer must perform a lot of additional checks to ensure the JMX specification is respected. I think using it in the container invocation chain (which should be able to support a LOT of invocations/second) would really slow down the container performance. Simon
