avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: JMX Integration
Date Sun, 01 Sep 2002 20:05:42 GMT


Huw Roberts wrote:
> Igor Fedorenko wrote:
> 
>> Is this already implemented? If not, do you need any help? In fact, 
>> something like that is a second item on my todo list, so I am going to 
>> do it in next couple of weeks anyways.
>>
>> Peter Donald wrote:
>>
>>> On Sun, 1 Sep 2002 08:07, Huw Roberts wrote:
>>>
>>>> Everything is ok until we get down to the management of individual jobs
>>>> - the rest can be already be done.  So the problem here is how is to
>>>> allow blocks to register additional objects for management 'beneath' 
>>>> them.
>>>
>>>
>>>
>>>
>>> yep.
>>>
>>>
>>>> Basically, the way I see this working is to have the BlockContext makes
>>>> it Management Context (an implementation of the SystemManager 
>>>> interface)
>>>> available to Block, and then use that to create a Jobs subcontext:
>>>>
>>>> SystemManager blockMgmtContext = blockContext.getManagementContext()
>>>> SystemManager jobMgmtContext = blockMgmtContext.getSubContext( 
>>>> "Blocks",
>>>> "Jobs" );
>>>
>>>
>>>
>>>
>>> Rather than this I think I may prefer something simpler - at least 
>>> initially. Something like
>>>
>>> BlockContext.register( String topic, String name, Object object )
>>> BlockContext.unregister( String topic, String name )
>>>
>>> Job jobOne = ... get the job somehow
>>> ctx.register( "jobs", jobOne.getName(), jobOne );
>>> ...
>>> ctx.unregister( "jobs", jobOne.getName() );
>>>
>>> The reason for this is that then we don't have to expose 
>>> SystemManager to clients and thus we are free to evolve it as we see 
>>> fit. However it exposes all the information needed to manage object.
>>> Like?
>>>
>>
>>
> 
> I have 3 issues:
> 1) The ability to add more than one level of hierarchy beneath the blocks.
> 2) Using an interface will make the client code cleaner and more portable.

+1

> 3) Client code will be hooking into this, meaning we are committed to 
> supporting it going forward.
> 
> I can live with this for now, but i want to consider how it fits into 
> the longer term direction.  What I'd like to do, is add a 
> ManagementContext interface to Framework, and then have SystemManager 
> extend this.  That would be the first step towards making the 
> functionality available in other containers.  Does that sound ok?  If 
> so, how do we proceed in that direction?  If its not too big a deal 
> maybe we could skip this intermediate step?

There is a project - excalibur/container - that is dealing with things 
like this.

   http://jakarta.apache.org/avalon/excalibur/container

It contains utilities and services that are container independent.  If 
you look at the framework is is 99% about the client view of a 
component. The excalibur/container package includes container indepedent 
interfaces that enable different implementations of common services. 
Something like a ManagementContext would make a lot of sense as a 
container-indepedent resource.

As a case study, the lifestyle extension package is limited to two 
interfaces and two abstract classes (very lightweight).  Both Merlin and 
Fortress provide alternative implementations of these interfaces.  The 
bottom line is that component authors are assured of the potential for 
portability of component that leverage these sort of concepts.

Cheers, Steve.



-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message