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 Wed, 04 Sep 2002 22:58:17 GMT


Igor Fedorenko wrote:

>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Peter Donald wrote:
>>>
>>>  >On Mon, 2 Sep 2002 02:45, Huw Roberts wrote:
>>>  >
>>>  >
>>>  >>>>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.
>>>  >>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?
>>>  >>
>>>  >>
>>>  >
>>>  >I would still prefer to go with the
>>>  >
>>>  >BlockContext.register( String topic, String name, Object object )
>>>  >BlockContext.unregister( String topic, String name )
>>
>>
>>
>> -1 a Context should never be used by a Container for its services.
>> If it is used, it's basically giving a service to everyone without IoC.
>>
>>> >The reason is that we have discussed that feature in the past 
>>> without  > really coming to any conclusion.
>>>
>>> Adding behaviour to an context implementation over and above the
>>> framework defintion of context means that you are defining a
>>> specilization of the Avalon Component Model for Phoenix.  Components
>>> that include a dependency on that model are no longer portable.
>>> Alternative solutions to introducing the functionality you are
>>> describing is totally possible without introducing the complication
>>> associated with BlockContext - i..e. use the context object to 
>>> aquire an
>>> abject implementing the interface the component needs, then apply
>>> register/unregister against that interface, or, havbe the copmponent
>>> declare a depedency on a registery service of some kind.
>>
>>
>>
>> I resist also this, since we are using services in a context, rather 
>> than be given them by the Container.
>>
>> I have looked in the archives and seen that once upon a time, Context 
>> was indeed used as a common service, and a common place to put services.
>>
>> I think that Context should never keep services where possible.
>>
>> For example, ServletContext is about instance data, not services.
>>
>>> This was discussed in respect to the shutdown request handler - this
>>> requirement is no different.
>>
>
> What if we provide instance of SystemManager via 
> ServiceManager.lookup()? I would not bother getting block's management 
> subcontext -- it does not map into anything in JMX anyways -- just put 
> root system manager into appropriate ServiceManager instance.
>

Sounds perfect - assuming that the component aquiring the SystemManager 
declares this as a dependency.

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