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 11:01:48 GMT
I am going to be moving this.  In the mean time can I get the author to 
apply the LICENCE.txt from spec/LICENSE.txt to each of these files.  
Note this license has a bit at the end which explains that these 
sources should not be touched, so be sure to use the right LICENSE.txt

Also, as I noted in the coding standards, public and public static are 
redundant in the context of interfaces and should not be used.

Can some one clean this up and resubmit this.

--jason


On Thursday, August 14, 2003, at 05:52  PM, James Strachan wrote:

> Patch applied - thanks Maas!
>
>
> On Thursday, August 14, 2003, at 11:34  am, 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>
>
> James
> -------
> http://radio.weblogs.com/0112098/
>


Mime
View raw message