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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
