geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: [jsr77][core] Components & Containers.
Date Mon, 15 Sep 2003 22:26:39 GMT

Dain,

+1 on your simplification (ie dumping the Abstract implementations).

we have too many classes with no real reuse at the moment - also some
of the synchronization concerns of AbstractManagedObject are pretty
tightly coupled with the statemanageable implementation.

I'll start work on removing AbstractStateManageable and renaming
to ManagedComponent and ManagedContianer based on AbstractManagedObject.
Patch ready later today (which I'll post around before a commit).

We then just need to work out what to do with the things based on
SimpleComponent and SimpleContainer (which I called AbstractComponent
and AbstractContainer in my renamed tree).

cheers


Dain Sundstrom wrote:
> 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 :)
> 
> 
> kernel:
> 
> <<ManagedObject>> <----------------+
> <<StateManageable>> <--------------+
> <<EventProvider>> <----------------+
> <<StatisticsProvider [1]>> <-------+
>                                    |
>                           AbstractManagedObject
>                                    ^
> 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.
> 
> -dain
> 
> [1] The AbstractManagedObject does not currently support 
> StatisticsProvider, but I'm sure it eventually will.
> 
> 



Mime
View raw message