geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: [JSR77] plug strategy proposal.
Date Tue, 19 Aug 2003 05:51:51 GMT

Dain Sundstrom:
>Can you tell me what your goal is,
My intent is to propose an implementation of JSR77, which could potentially 
be re-used.

>and maybe how a kernel component is different from a StateManagedObject?
The kernel component of Geronimo is a StateManageableObject. It is 
effectively pointless to apply on its top an additionaly layer providing a 
StateManageable view of its behavior.

However, the kernel component of other application servers is not compliant 
with the StateManageable, EventProvider and StatisticsProvider requirements. 
The proposed implementation provides a set of instrumentation hooks to 
expose a JSR77 model without having to refactor - to some extent - the 

>I really don't understand why we need this abstraction layer.
I would like to remove from the type hierarchy of the kernel components the 
specificities of JSR77.

The proposed implementation will works like this:

For the event notifications:
kernel component -> EvtProvInst -> JSR77 Model

For the state manageable behavior:
JSR77 -> StateManageableInst -> kernel component

For the statistics:
kernel component -> StatsProvInst -> JSR77 Model.

More generally:
kernel <-> Instrumentation hooks <-> JSR77 Model <-> MEJB

As far as I know, we are going in this direction:
kernel <-> MEJB

It is more straigth forward. However, it means that the JSR77 requirements 
are embedded in the kernel. The proposed solution exports these 
requirements. This is perhaps a better separation of concern.


MSN Search, le moteur de recherche qui pense comme vous !

View raw message