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 *************************/
