Re: [jsr77][core] Components & Containers.

[gianny DAMOUR]

It does appear that our current AbstractComponent and AbstractContainer
really should be ManagedObjects and it is simple to make them implement the
ManagedObject interface.
I agree. Actually, I believe that it should be nice to have it this way due 
of the specifications:

"Vendor-specific managed object type models must extend the 
J2EEManagedObject type and support the attributes required by the 
J2EEManagedObject model."

In other words, AbstractComponent and AbstractContainer could then be 
considered as "Vendor-specific managed object types" as they expose a 
J2EEManagedObject.

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.
I agree: AbstractStateManageable should be used as a foundation for 
AbstractManagedObject. However, I am partially agree on the implementation.

A J2EEManagedObject can expose either a StateManageable, EventProvider, or a 
StatisticProvider interface. Hence, perhaps that a composition will be more 
handy:

AbstractManagedObject implements only the J2EEManagedObject contract. Its 
isStateManageable, isEventProvider and isStatisticProvider operations return 
"false" (just right now, isStateManageable is final and return "true"). It 
also implements the StateManageable, EventProvider and StatisticProvider 
interface.

Components having a manageable state extend AbstractManagedObject and 
delegate the state requirements to GeronimoStateManageable (== 
AbstractStateManageable). The isStateManageable is overriden, declared as 
"final" and returns "true".

Components emitting events extend AbstractManagedObject and delegate the 
event requirements to GeronimoEventProvider. The isEventProvider is 
overriden, declared as "final" and returns "true".

Components providing statistics extend AbstractManagedObject and delegate 
the statistic requirements to GeronimoStatisticProvider. The 
isStatisticProvider is overriden, declared as "final" and returns "true".

AbstractManagedObject would end up with three additional fields:
GeronimoStateManageable m_stateManageable;
GeronimoEventProvider m_eventProvider;
GeronimoStatisticProvider m_statisticProvider;
initialiazed with instances, which throw exceptions, e.g. 
OperationNotSupportedException, in order to prevent their misuse if they are 
not redefined by a sub-class (kind of Strategy pattern).

These three additional fields are used to implement the StateManageable, 
EventProvider and StatisticProvider interface:
...
public void start() {
 m_stateManageable.start();
}
...

In order to provide a call-back, for instance for the 
AbstractStateManageable.doStart method, AbstractManagedObject implements an 
interface TBD.

The overall picture could be:
<< EventProvider >>     <<StatisticProvider>>        <<StateManageable>>
           ^                                  ^                             
           ^
           |                                    |                           
              |
            - - - - - - - - - - - AbstractManagedObject - - - - - - - - - - 
- -
                                   /            |                  \
      ----------------------------              |                    
----------------------------
      | 1..1                                  | 1..1                        
                 | 1..1
      \/                                       \/                           
                   \/
GeronimoStateManageable GeronimoEventProvider GeronimoStatisticProvider

Cheers,
Gianny
_________________________________________________________________
Get a FREE computer virus scan online from McAfee. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963