geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bordet, Simone" <>
Subject RE: Dynamic MBeans. Was: Kernel Architecture
Date Tue, 12 Aug 2003 19:13:03 GMT

> 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.


View raw message