geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: Dynamic MBeans. Was: Kernel Architecture
Date Tue, 12 Aug 2003 13:46:36 GMT

On Tuesday, Aug 12, 2003, at 14:20 Europe/London, James Strachan wrote:

>
> On Tuesday, August 12, 2003, at 02:07  pm, Greg Wilkins wrote:
>>>> 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 
> flexible.

What about creating an interface, say, ManagedComponent, that component 
authors could implement? Then we can move any JMX/MBean specific 
behavoir into that interface (or an AbstractManagedComponent abstract 
class) and let developers subclass that?

A convention like XxxComponent or XxxService may also be more 
meaningful to developers. Are there any other major types of code in a 
server? XxxAgent, Xxx??? If we can have placeholders for these, then 
future components can be described as one (many?) of these.

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

Yes, having an externalised/automatically generated MBean is probably a 
good way to go.

>> 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 your code has no dependencies on JMX - though 
> we should be able to use better / simpler mechanisms for this.

IMHO the naming convention of MBean does tie it down, though; from the 
JMX spec:

JMX_1-2 p37: "The name of an MBean's Java interface is formed by adding 
the 'MBean' suffix to the MBean's fully qualified Java class name. For 
example, the Java class MyClass would implement the MyClassMBean 
interface"

Not having the naming convention would then make it clearer if MBeans 
were not to be used later. However, the principles of still having the 
getters/setters is a clear and easy step for developers to be able to 
interact with it, in whatever means.

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

Externalising the MBean descriptors (and the subsequent automatically 
generated code) might be a way of implementing security as an aspect on 
top of that?

Alex.


Mime
View raw message