geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <davidjen...@snappydsl.net>
Subject Re: Dynamic MBeans. Was: Kernel Architecture
Date Wed, 13 Aug 2003 04:15:04 GMT

On Tuesday, August 12, 2003, at 03:13 PM, 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) ?

-- you can deploy a pojo as an mbean with __no__ modification or 
interface required.  For instance, in JBoss 4, the jca adapter objects 
are deployed directly as xmbeans.  Thus you can see and modify all the 
properties of a deployed ManagedConnectionFactory instance.
--"artificial" attributes that are not actually in the underlying 
object.
--attributes whose accessors don't follow the standard mbean naming 
convention
--you can include lots of descriptive info to display in a management 
console.  This makes the console self documenting.
--with an interceptor based model mbean implementation, you can add 
interceptors that implement additional operations.  For instance, in 
the JBoss 4 jca 1.5 support, ActivationSpec instances are deployed 
directly as xmbeans.  There is an no-arg "start" operation implemented 
by an interceptor that is called by the JBoss lifecycle management and 
in turn calls the jca start(ResourceAdapter) method.  (the ObjectName 
of the deployed resourceadapter instance is held in an "artificial" 
attribute).
>
> 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 ?).

How can you generate the metadata without at least minimal source code 
markup?  What is the useful stuff you are thinking of?
>
> 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 ?
Too similar for what?
>
>> 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 ?
How would it decide which operations/attributes should be exposed?  For 
the jca stuff I mentioned, the needed metadata is specified in the 
ra.xml file.
> 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.

I think it depends on what is in the interceptor chain...

david jencks
>
> Simon
>


Mime
View raw message