Patch applied - thanks Maas!
On Thursday, August 14, 2003, at 11:34 am, [EMAIL PROTECTED] wrote:
Hi,
I hope nobody else has already done this, but I've 'implemented' the bare javax.management.j2ee.* interfaces. - Cleanroom, used javadoc only. - Copyright is assignable to ASF.
Maas
Citeren gianny DAMOUR <[EMAIL PROTECTED]>:
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
<jsr77-src.jar>
James ------- http://radio.weblogs.com/0112098/
