geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [jsr77][core] Components & Containers.
Date Mon, 15 Sep 2003 18:18:59 GMT
On Sunday, September 14, 2003, at 11:25 PM, Greg Wilkins wrote:

> It does appear that our current AbstractComponent and AbstractContainer
> really should be ManagedObjects and it is simple to make them 
> implement the
> ManagedObject interface.

+1  The StateManageable thing was just a mistake.

> Also instead of renaming them to StateManageableComponent & 
> StateManageableContainer
> (as per my previous email) I think it makes more sense to rename them 
> to
> ManagedComponent and ManagedContainer

+1  because they are more then StateManageable; they are EventProviders 
and StatisticsProviders.

> However, they should probably extend AbstractManagedObject - which 
> currently
> duplicates much of the content of AbstractStateManageable.  Thus I 
> think
> AbstractStateManageable should be moved to kernel and used as the base 
> for
> AbstracteManagedObject.

This is where I disagree.  I don't think we should have 
AbstractStateManageable at all.  Will we ever have something that is 
StateManageable and not a ManagedObject? No JSR 77 management system 
will recognize it because it will not have the isStateManageable method 
from the ManagedObject interface.

> Thus we would end up with the following hierarchy:
> kernel:
> <<StateManageable>>
>                                                           ^
>                                                           |
> AbstractStateManageable
>                                                           ^
>                                                           |
> AbstractManagedObject
>                                                           ^
> core:                                                     |
>          <<Component>>  <--- AbstractComponent  <---  ManagedComponent
>              ^                 ^                          ^
>              |                 |                          |
>          <<Container>>  <--- AbstractContainer -----o ManagedContainer
>                  ^                                    /
>                   \                                  /
>                    ----------------------------------

Damn you are getting good at ASCI art :)


<<ManagedObject>> <----------------+
<<StateManageable>> <--------------+
<<EventProvider>> <----------------+
<<StatisticsProvider [1]>> <-------+
core:                              |
          <<Component>> <--- ManagedComponent
              ^                     ^
              |                     |
          <<Container>> <--- ManagedContainer

For ManagedObjects all of the interfaces except ManagedObject are 
optional.  I just don't see anyone ever using an implementation of 
StateManageable without doing the a full managed object.  I feel the 
same way about EventProvider and StatisticsProvider.

I also don't see why we need AbstractComponent and AbstractContainer.  
If we find a need later, we can extract the abstract implementations 
(just a few clicks in Eclipse and IntelliJ).

I think this model is much simpler hierarchy, will be quite easy to 
understand, and most importantly it is what we need today.

On an related issue.... I also need to fill you in on the 
GeronimoMBean, as we either must use the GeronimoMBean for all of our 
ManagedObject implementations or we must change the 77 interfaces.  The 
problem is 77 call for attribute names like "startTime" where the first 
character is lowercase.  If we are using StandardMBeans then the getter 
and setter must be getstartTime and setstartTime (it is an mbean spec 
thing that we can't fix).  Since the GeronimoMBean is a dynamic MBean, 
we can fix the capitalization issues, and that is what I did.

I'll try to pull together some docs on it this week.


[1] The AbstractManagedObject does not currently support 
StatisticsProvider, but I'm sure it eventually will.

View raw message