geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Dynamic MBeans. Was: Kernel Architecture
Date Tue, 12 Aug 2003 13:20:23 GMT

On Tuesday, August 12, 2003, at 02:07  pm, Greg Wilkins wrote:
> James Strachan wrote:
>>>> An interface based MBean is just a naming convention. There is no 
>>>> tying to anything. Indeed there's not even a dependency on JMX 
>>>> never mind any other container API. Then the container is totally 
>>>> free to go in whatever direction it wishes.
>>> But by creating (and calling) them MBeans, you are tying it down to 
>>> a naming convention expected by JMX which may confuse the issue 
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be 
>> any less confusing?
> Why can't we go for a totally dynamic MBean model?

We absolutely could. I was trying to just come up with a simple 
convention component authors could follow - though we should be 

> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?

No reason why we couldn't do that. Could use XDoclet or an XML config 
file or some clever build process to generate the MBean or dynamic 
MBeans whatever.

> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.

Agreed - though at least it works :). i.e. its the minimum requirement 
for a component/service author.

> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.

I'm cool with alternative forms of getting to the same place. i.e. 
however the MBeans are written - whether they are just POJOs or beans 
and we adorn them to be MBeans or we follow the MBean interface or we 
use some XML deployment descriptor for the MBean metadata - I'm easy. 
It can then be the developers choice.

I personally quite like the MBean interface idea as it makes 
refactoring easier and you're code has no dependencies on JMX - though 
we should be able to use better / simpler mechanisms for this.

> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data.  We can also expose
> more of an object simply by changing the MBean descriptor file.



View raw message