geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@coredevelopers.net>
Subject Re: [JSR77] Workplan proposal
Date Thu, 14 Aug 2003 10:52:21 GMT
I am moving all specs to a separate module.  I will look at this when I 
have moved what we have already.

--jason


On Thursday, August 14, 2003, at 05:34  PM, email@dds.nl 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 <gianny_damour@hotmail.com>:
>
>> 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>

Mime
View raw message