geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject [JSR77] Workplan proposal
Date Thu, 14 Aug 2003 09:24:51 GMT

Greg, thanks for the partial commit of “State Manageable Object”. I highly 
appreciate it.
< /by-the-way >

I have very quickly defined a potential work-plan for JSR77. Could you 
please provide your feedback?

The goal is to have a “stable” workplan approved by all in order to 
bootstrap with confidence the implementation of JSR77. Once approved, one 
publishes it on the Wicki and starts the build.


1. Implement the models and metamodels specified by JSR77.3.

Based on the specifications, the namespace of these (meta)models is 
implementation specific.

Excerpt of the JSR77.3:
Although the diagrams and textual descriptions that specify the managed 
types closely resemble Java classes, they are not specifications of Java 
class types or
Java class inheritance hierarchies and do not represent requirements of the 
names or class hierarchies of a particular implementation.

I propose to create this model under the org.apache.geronimo.j2eemanagement 

Moreover, based on the fact that this package is decoupled – by now – of the 
core container, it should be great to implement JSR77 in a distinct 

2. Define the global strategy to plug this implementation.

It seems that the current strategy is to expose this implementation via 
inheritance. Indeed, the AbstractComponent extends AbstractStateManageable.

This is a possible implementation. However, based on the specifications, a 
managed object may optionally implement the StateManageable model; may 
optionally implement the StatisticsProvider model; and may optionally 
implement the EventProvider model. In other words, if one decides to go in 
this direction, then AbstractComponent will need to be extended by an 
AbstractStateStatisticsEvent class, which uses under the cover an 
AbstractStateManageable, an AbstractStatisticsProvider and an 
AbstractEventProvider abstracting the three optional models.

I am sure that this is doable.

However, what do you think of trying to plug the components via a Strategy 

Consider the following example:

public class interface J2EEManagement {
  public void setStateManagement(StateManageable);
  public void setStatisticsProvider(StatisticsProvider);
  public void setEventProvider(EventProvider);

public class EJBComponent extends <whatever> implements J2EEManagement{

   EventProvider m_eventProvider;

  // partial J2EEManagement implementation.
  public void setEventProvider(EventProvider anEventProvider) {
    m_eventProvider = anEventProvider;
    m_eventProvider.setSource(this); // for callbacks.

  doStart() {
      m_eventProvider. doNotification(<a starting notification here>);
      // perform the state update
      m_eventProvider. doNotification(<a started notification here>);

This way, the type hierarchy of core components – as an EJBComponent – is 
simple and do not expose some optional attributes and operations.

It is true that a managed component, which, for instance, emits events must 
implement the EventProvider model. However, a managed component is a “unit 
of management information”. In other words, EJBComponent may or may not 
implement the EventProvider model. However, its J2EEManagement counterpart 
MUST implement it.

3. Implement the Events (JSR 77.4.1); State Management (JSR77.5.1); and 
Performance Monitoring (7.6.1) of the specifications. These tasks can be 
done in parallel.

4. Implement the means MEJB (JSR77.7.1); SNMP (JSR77.8.1); and CIM (JSR 
77.9.1) to interact with the J2EE management (meta)models.


Hotmail : un compte GRATUIT qui vous suit partout et tout le temps !

View raw message