geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [JSR77] plug strategy proposal.
Date Tue, 19 Aug 2003 15:01:06 GMT
On Tuesday, August 19, 2003, at 12:51 AM, gianny DAMOUR wrote:

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

Reused by whom?  ...by some other container using something other then 
JMX.  I really don't see a demand for this, and adding another layer of 
complexity (for something we don't plan on using) at this stage seems 
like a bad idea.  If it becomes a priority later we can easily add the 
abstraction in.

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

The deployment system works with non 77 compliant components right now. 
  You just don't get life cycle objects.  I will be adding a Model MBean 
which will wrap any java object and provide the live cycle transition 
among other features.

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

Our deployment system is fundamentally based on 77, but our kernel only 
understand JMX and specifically doesn't do any 77 stuff.  77 is really 
handled by the components, if they don't implement it properly the 
kernel doesn't care.  Other components will care if they depend on 
something that does not properly implement the life-cycle, but the 
kernel doesn't care in the least bit.

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

I really don't know what you mean by 'embedded' here.  The kernel, JMX, 
does support our event model.

I really don't see this as the real problem right now.  The real 
problem is that to reuse any of our life-cycle code, you must extend 
AbstractStateManageable.  I plan on adding support with a ModelMBean to 
add reuse by having a common MBean implementation that will delegate to 
a user component, and as an alternate I would like to add a 
StateManageableDelegate which a user component can delegate to.

-dain

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/


Mime
View raw message