geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject [JSR77] plug strategy proposal.
Date Mon, 18 Aug 2003 11:26:59 GMT

I tried to produce a working piece of code showing how a JSR77 
implementation could be separated from the kernel by exposing some 
instrumentation hooks.

More accurately, here is a short description of the general idea:

A kernel component, KC, mirroring a J2EE managed object, MO, implements the 
following interface:

public interface InstrumentationHook {
    public J2EEManagedObject getManagedObject();
    public void setEventProviderInst(EvtProvInst anEvtProv);
    public StateManageableInst getStateManageableInst();

KC creates its corresponding MO.

KC calls MO.setEventProvider() in order to notify MO that it emits events. 
If KC emits events, then MO calls back KC via the setEventProviderInst() 
method. The instance passed to KC is an event provider instrumentation hook 
used by KC to send event to the JSR77 model.

KC calls MO.setStateManageable() in order to notify MO that its state is 
manageable. If the state of KC is manageable, then MO calls back KC via the 
getStateManageableInst() method. The returned instance is an instrumentation 
hook used by MO to manage the state of KC.

Regarding the statistics, I assume that the same mechanism could be applied.

What I like in this implementation is the fact that it is orthogonal - to 
some extent - to the kernel. More accurately, it could potentially be a 
re-usable component. The kernel deals with the instrumentation hooks 
provided by the implementation and that is it.

Let me know if this proposition makes sense and if it worth the price to 
investigate more in this direction or if I should give up.


MSN Messenger 6 : ajoutez une image à votre 
pseudo pour dialoguer avec vos amis

View raw message