geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pasi Salminen <>
Subject Re: Dynamic MBeans. Was: Kernel Architecture
Date Wed, 13 Aug 2003 07:35:50 GMT

At least I'm in favour of model MBeans. They can be described in XML (which I think is a good
idea) and they can have annotations. What does it say to an administrator if he can see an
operation stop? For us (being professional J2EE propeller heads) it may be obvious but
for an administrator it would be nice to see some description of the operation or attribute
he is trying to invoke or manipulate. That's why model beans are nice. And if the configuration
file is implemented so that it can "dig" information out of the bean (if not
overridden in the XML configuration) that's cool and keeps configuration simpler.

Also, I think it would be good idea to use just simple types in the interface of the beans.
Otherwise integrating those beans with management consoles gets really nasty (for example,
compiling some stuff again or adding classes to classpath of the console).

Secondly, I don't understand why some of you are so afraid of JMX. Nobodys afraid of HTTP
fading away. It's there in the spec and it'll be part of the server anyhow, just like servlets.

However, whoever has proposed JMX (kernel) to be used as an invocation bus, I not sure if
I agree with him/her. The MBeans could just expose, for example the HTTP support, and from
then on it just controls when to stop it and how to get performance metrics (etc) from it.
Inter-service bindings/lookups could of course be implemented with JMX relation service...

Br. Paci

"Bordet, Simone" wrote:

> 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


This message and its attachments have been found clean from known viruses 
with three different antivirus programs.

View raw message