is there anybody managing who should do which part ? as i've seen i the sources there are many @todo-Tags around.
please let me know what i can do.
in the meantime i should read the spec in detail.
Bodo
gianny DAMOUR schrieb:
Hello,
<by-the-way>
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.
Work-plan:
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 object
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 class
names or class hierarchies of a particular implementation.
“
I propose to create this model under the org.apache.geronimo.j2eemanagement package.
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 sub-project.
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 pattern?
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.
Cheers, Gianny
_________________________________________________________________
Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! http://g.msn.fr/FR1000/9493
